对于网络知识的梳理（TCP/UDP/HTTP/HTTPS/DNS）

首先从http协议说起，先附上两张图，分别是网上找的请求报文与响应报文的示例图：

请求报文：

由此可以看出，请求报文的结构为：

第一行（第一部分）：请求方法，请求地址URL，协议版本（一般为HTTP/1.1）

第二部分：首部字段名与其对应值的区域，例如code、cookie、content-type等

第三部分：实体主体，就是装载我们实体请求内容主体的地方

这三部分构成了请求报文的内容。

 

响应报文：

由上文可看出，响应报文与请求报文的结构相类似

第一行（第一部分）：首先第一个字段是版本号，一般为HTTP/1.1，第二个信息是返回值，也叫做状态码，表示连接请求所返回的状态，第三个值就是短语，以表述状态码的描述。

第二部分：跟请求报文一样，是一个装有首部字段名与其对应值的区域，用换行符隔开

第三部分：就是响应主体

 

以上两个部分就构成了HTTP请求基本的结构，一请求一相应的报文信息传递。

HTTP的请求方法：

GET：请求指定的页面信息，并返回实体主体

POST：向指定资源提交数据进行处理请求。指定数据被包含在请求体中。

HEAD：类似于GET方法，只是不会返回内容主体，只会返回报文头

PUT：客户端向服务器发送消息，类似于增删改查中的“增”

DELETE：客户端向服务器发送消息，删除指定数据

OPTIONS：获取服务器支持的HTTP方法，检查服务器性能

TRANCE：返回服务器收到的请求，主要用于测试所用

CONNECT：CONNECT这个方法的作用就是把服务器作为跳板，让服务器代替用户去访问其它网页，之后把数据原原本本的返回给用户。这样用户就可以访问到一些只有服务器上才能访问到的网站了，这就是HTTP代理。

前三个GET、HEAD、POST方法是在HTTP/1.0中就存在的请求方法了，HTTP/1.1中新加入了，PUT,DELETE,OPTION,TRACE,CONNECT五种新增的请求方法。

在其中，关于GET和POST的方法区别有以下几点：

就语法的区别来说：GET的请求会拼接在请求URL之后，通常请求内容有2048字符的限制，而POST方法会将请求放在请求体BODY中，并且请求内容长度没有限制。同时GET请求不安全，容易被截获，而POST请求安全一些。

如果从语义的角度上来说呢：GET请求对于服务器来说是安全的，且具有幂等性，而且可缓存。因为GET请求本质上是向服务器获取数据，并不会对服务器的数据造成影响，所以说是安全的，且多次请求的结果是和一次请求的结果一致的，所以具有幂等性，并且浏览器会对GET请求自动做缓存处理。

而POST请求会对服务器的数据造成影响，所以对于服务器来说是不安全的，且不具有幂等性，并且浏览器也不会自动缓存POST请求的数据。

对于服务器来说具有安全性的请求方法有：GET HEAD OPTIONS,可缓存性的方法有：GET HEAD

关于HTTP请求的状态码一般分5个类别，分别是1，2，3，4，5开头的三位数字

1开头的数字：一般表示服务器已经收到了请求，要求请求者继续操作

2开头的数字：一般表示服务器成功接收并成功处理了一部分或者全部的请求

3开头的数字：一般是数据重定向的问题，表示服务器已经成功接收了请求，但是需要请求者进一步操作以完成请求

4开头的数字：一般是客户端错误，比如请求的资源不存在或者请求内容有误等问题

5开头的数字：服务器错误，一般是服务器在处理请求过程中发生了错误等。

常见的状态码有：200表示成功请求数据并返回。301表示资源被转移到了其他URL。404表示请求的资源不存在，找不到。500表示服务器内部出错。400表示请求语法错误。401表示需要身份认证。402表示保留。403表示请求被服务器拒绝执行。405表示请求方法被服务器禁止。

关于HTTP建立的连接是基于TCP传输的，但是一个短连接的过程，三次握手后进行HTTP交互，再进行四次挥手断开TCP连接。

HTTP是一种无状态，无连接的协议，所以为了解决这两种办法，持久连接和Cookie/seesion的出现便引出了。

关于持久连接则是一般一次HTTP请求的过程为，客户端先与服务端建立一个三次握手的TCP链接，随后向服务端进行一个HTTP请求，一问一答，之后再进行四次挥手断开连接的流程。要知道客户端与服务端建立三次握手与四次挥手的过程同样是需要消耗时间的，比如在多次连续的请求下就会走多次这样的流程，是非常消耗性能的。持久连接的产生就解决了这个问题，在服务端和客户端可以建立一个协议，在多少次请求之后或者多少时间后再断开连接，这样的话在多次请求的过程中就会复用这一个持久建立的TCP通道了。

在HTTP1.0版本时，持久连接默认是close状态，需要在报文头中的Connection字段加入keep-alive来进行持久连接的建立，而在HTTP1.1版本默认就是开启了keep-alive状态，只有将报文头字段中的内容改为close时才会不建立持久连接。

在持久连接中有两个重要的参数，一个是time，表示客户端希望与服务器建立持久连接的时间或者服务端希望与客户端建立持久连接的时间，另一个是max，表示在这段持久连接中需要进行请求的最大次数，一旦达到这个次数就进行断开持久连接的响应。

关于如何判断消息传输完毕，断开持久连接，一种是根据报文头的content-length来判断数据是否发送或者收取完毕，另一种情况当不能确定数据的大小时，使用chunk编码来确定消息是否传输完成，当数据在TCP中进行传输时，会被分割成一部分一部分的报文段，而这些报文段都采用chunk编码来实现，chunk编码是对应一个表示长度的内容与一个表示实体内容的内容，当我们判断消息传输结束时，最后一个chunk编码的长度会为o，这样就判断了消息已经传输完成，可以断开连接了。

这里，对于HTTP协议的总结就差不多结束了。

其实HTTP协议也是一种不是很安全的协议，有些时候会遭遇到中间人攻击的问题，就是中间人模拟客户端与服务器，当客户端给服务器发送消息时，截获，然后冒充客户端再给服务器发送消息，当服务器返回消息时，截获，又冒充服务器给客户端发送消息，这个其实就是通常所说的“抓包”，我们开发时候喜欢用的“花瓶”charles就是这个原理。

对此，HTTPS这种附带加密算法的协议就产生了。

HTTPS是一种安全的加密协议，其组成是在TCP传输层与HTTP应用层之间增加了一层网络传输安全协议层，SSL/TLS协议，来保证数据传输的安全性与TCP连接建立的安全性，极大程度保证了避免中间人攻击的情况发生。

在HTTPS协议中，客户端与服务端建立连接的流程也增加了加密的流程，简述为下：

1.客户端向服务器端发起建立连接的请求，同时生成一个随机数c，发生自己的TLS版本号以及支持的加密算法

2.服务器收到客户端发来的数据后，选择一种对应的加密算法告诉客户端，同时生成随机数s，向客户端发送server证书

3.客户端拿到服务器发来的确定的加密算法后，生成随机的预主秘钥，同时根据自己产生的随机数c与服务端发来的随机数s组装成对应的会话秘钥，同时用服务器发来的公钥将预主秘钥加密，发送给服务器端。

4.服务端收到预主秘钥后同样用随机数c与随机数s结合，通过加密算法组装成会话秘钥。

5.这是便开始了与服务器进行三次握手的过程，客户端将握手消息通过会话秘钥加密，发送给服务器

6.服务器同样将相应信息通过会话秘钥加密发送给客户端

7.客户端同理第三次发送消息

这时TCP连接就建立了，随后的数据发送与接收以及四次挥手的相关连接信息都会通过加密的方式告诉对方，这样就极大程度的保证了数据的安全性。

HTTPS在连接建立的过程中会使用非对称加密，也就是公钥与私钥的加密，进行信息的加密，但是非对称加密的缺点就是非常耗时，不可能在之后的大量数据传输过程中使用大量非对称加密。所以除了连接建立的时候使用非对称加密，其他时候的信息加密用的都是双方的会话秘钥，也就是私钥加密。这种就是对称加密方式。

UDP协议：

UDP协议也称为用户数据报协议，UDP采用无连接，尽最大努力交付，面向报文的特点，使利用UDP在网络中进行传输的成本非常小，一些要求即时性较高的场景非常适合UDP这种协议的使用：例如QQ电话，即时会议，视频通话等。UDP不会保证数据的完整性，而是尽最大努力交付，而这些场景恰好也允许个别数据的丢失，但是会要求即时性，也就是在网络中传输的延迟需要最低化，UDP也不会对报文进行划分或者整合，而是直接将应用层传输的报文加上传输层首部就发送。UDP是没有拥塞控制的，很多的实时应用要去源主机以恒定的速率发送数据，并且允许在网络发生拥塞时丢失一些数据，但却不允许数据有太多的时延。UDP正好符合这种要求。 

UDP拥有分用，复用的特点，不同端口号发送数据可以复用同一个UDP传输，反之同理接收数据也可以使用同一个UDP通道收到数据，再分发给不同的端口。

TCP协议：

TCP是一种可靠传输的传输协议，拥有面向连接、可靠传输、面向字节流、拥塞控制、流量控制等特点。

其面向连接特点可解释为拥有三次握手与四次挥手的连接与断开连接流程，所有的数据传输都是建立在连接的基础上进行的。

三次握手是因为要确定一次连接的建立，三次通信是最高效也是最低差错的方法。如果是2次连接，当客户端误发送2次建立连接的请求时，服务器一定会建立2个连接通道，这样就造成了资源的浪费，所以三次连接避免了这种情况发生，4次连接是傻逼的做法。。这里就不解释了。

关于四次挥手的主要原因是，TCP建立的通信通道是全双工的，任意一方断开连接都需要双方的确认才行。所以会建立4次挥手。

 

TCP的可靠传输机制：

TCP拥有无差错情况，超时重传，确认丢失，确认迟到四个机制来保证其实可靠传输的连接：

其是一次发送数据就有一次数据确认的机制，保证了其是无差错情况的可靠连接。

当一次发送数据后如规定时间内收不到响应报文，就会进行超时重传的机制，这种情况分几种：

1.发送的报文是有错的报文或网络传输中造成了报文错误或者报文不完整。这时接收方判断数据有误，不会进行确认报文的发送，而发送方在一定时间内没有收到确认报文，便会进行2次报文重传，如果第2次发送接收方确认OK，便会返回确认报文，这时发送方接收到了确认报文，才会进行第二次报文的发送。

2.确认报文丢失。这种情况发送方在规定时间内没有收到确认报文便会进行超时重传，这时接收方收到了上一次相同内容的报文，首先会对新的报文进行丢弃，其次再次发送一个确认报文回给发送方，接收方如果接受到了确认报文，才会进行下一次报文的发送，没有，则重复。

3.确认报文迟到。这种情况就是上面一种情况的延伸，如果当发送方已经重新发送了新的报文，并且已经收到确认报文了，这时候上一个确认报文才到，遇到这种情况发送方就收下迟到的确认报文，然后什么也不做，继续进行连接内的数据传输。

 

TCP是一种面向字节流的传输连接：

TCP连接传输报文的特点是面向字节流的，其内部有一个类似BUFFER的东西，会将接收到的报文分割或者合组，当大小满足其一个BUFFER的大小时才进行发送，这就是TCP的面向字节流的特点。

 

关于TCP协议的流量控制特点：

TCP中的流量控制主要是使用了滑动窗口协议来控制的，其目的就是在于会根据接收方接收能力的大小，动态来调整发送方的发送速率，达到一个流量控制的目的。在TCP接收方和TCP发送方的两头，其实传输数据的过程中各自有一个接收缓存和一个发送缓存，而在接收缓存和发送缓存中，又存在一个可以动态调整区域的部分，我们形象化说明其为一个可调整大小的滑动窗口，在TCP发送端中，发送缓存中的报文序号是从左向右依次增大的，而每一次发送的报文中，发送顺序也是从低发到高的，但是由TCP接收方中发送的确认报文，其实是由大到小的，可以说是每一次发送的数据中，确认数据的回执是倒叙的，只有当第一个发送的数据的确认报文达到时才会发送下一批数据。而当我们的发送端和接收端的网络能力不同时，也会造成相应的问题，比如发送端的网络很好，一次发的东西很多，而接收端此时的接收能力很弱，就会造成数据拥堵，或者处理能力跟不上这种情况，所以滑动窗口就是为了处理这一种情况而产生的。当接收端的接收能力不够时，会通过相应通讯的TCP报文头告诉发送端，此时的发送窗口应该调小，这时发送端接收到了相应的消息，就会将每一次发送数据的发送窗口范围调小，来配合接收端降低发送速率，而当接收端将信息处理得当后，此时网络状况同时也得到提升的情况下，会通过相应的报文头告诉发送方，将滑动窗口调大，这样发送方一次发送的数据就会更多了。而每一次接收方在接收窗口收满之后，也会将接收窗口中的内容进行详细排序后再传送给应用层，所以滑动窗口协议不仅保证了TCP传输协议中的流量控制，也是数据按序到达的一个保障因素。这就是TCP中滑动窗口协议的特点。

 

关于TCP拥塞避免的特点：

TCP是拥有慢开始，拥塞避免、快恢复，快重传的特性的。

所谓TCP的拥塞避免机制，其实就是在TCP开始进行传输时，随着交互次数的增多，TCP中传输报文，也就是传输窗口的数量先是会进行一个指数的增长，当其数量到达门限值16的时候，为了避免服务器的数据拥塞，其增长的方式降低为加法增长，来限制传输的增长速度，当增长到TCP中判断该情况下已经造成了网络数据拥塞的时候（网络拥塞判断很复杂，可以简单理解为比如三个确认到达的ACK都没有收到这种情况），就会记录当前的窗口数量，并且迅速将发送的窗口数量降低为1，然后将新的门限值设置为拥塞窗口的一半，随后立即开始重传，重复之前的指数增长，然后到达新的门限值之后变为加法增长，来避免网络拥塞。这就是TCP中拥塞避免的机制，其特点为慢开始，拥塞避免，快恢复，快重传。

 

DNS：

我们通常上网都是输入的一个具体的域名，例如www.baidu.com，而真正与服务器通信需要一个准确的IP地址才行，所以DNS就油然而生，其目的就是为了解析一个域名。DNS就是一个从域名到IP地址的映射，如果需要向DNS服务器请求IP地址，使用的是UDP数据报，且是明文。

DNS的查询方式分为两种，一种是迭代查询，一种是递归查询。前一种查找顺序是由上而下，后一种查找顺序是由下而上。递归查找方式就是从本地服务器开始，一层层向上查询，直至对应DNS服务器返回了IP地址。迭代查询就是从权限DNS服务器开始，逐级向下，或者某一级DNS服务器准确返回应去哪一级DNS服务器查找，直至返回IP地址的查找方式。

常见的DNS劫持方式也是类似于HTTP的中间人攻击方式，攻击人会劫持DNS服务器，在客户端向DNS服务器请求IP地址时，返回错误的IP，导致客户端连接到错误的服务器。解决这种情况的方法有二：1.使用httpDNS，将DNS请求处理为一个类似于HTTP请求的情况，使用http协议向DNS的80端口号进行请求而不是使用DNS协议向DNS服务器的53端口号请求。2.或者使用长连接方案进行DNS请求，先将请求端与一个既定的server进行长连接，随后server端一般与内网的DNS服务器进行请求，随后将请求到的数据通过长连接返回给请求端，就达到了DNS请求的目的。

常见的DNS问题还有转发的问题，比如要访问一个百度的域名，一般小厂网路运营商的DNS请求处理都挂靠在大厂的DNS服务器上，比如你的网络是移动，有可能进行某些网站DNS解析的时候，移动会将这个DNS请求转发至电信的DNS服务器上，再由电信的DNS服务器向权威DNS服务器进行IP地址的请求，这时候请求到的IP地址可能就是该网站对于电信运营商提供的相应网站服务器，这时候用你的移动服务器向该地址进行请求数据就有可能造成无响应，或者访问过慢等问题。

 

session/cookie：

session/cookie是对于HTTP协议无状态的一种补偿机制， 他们存在于HTTP协议报文的报文头中，在请求报文中cookie与session被保存在Cookie字段中，在响应报文中被保存在Set-Cookie。

Cookie的特点是保存在客户端，而session的特点是保存在服务端，让服务端来判断状态。这是它俩最大的区别，显而易见，seesion是较为安全的，那么怎么保证cookie的安全呢？1.对cookie进行加密处理2.只在HTTPS上使用cookie3.设置cookie为httpOnly，防止跨站脚本攻击。满足这三天就达到了最大限度的cookie安全处理。对于cookie的修改与删除操作其实是同样的原理的，都必须使用一个新的cookie与原cookie中name,path,domian等基础信息一致，之后作覆盖处理。而删除cookie就是将cookie中的expires设置为过去的一个时间点，让cookie过期，或者将maxAge指为0，表明该cookie已过去。这样就完成了cookie的删除与修改。

 

以上就是花了一天梳理的全部网络相关的知识内容，希望可以帮得到你。

 

 

 

 

本文章由作者原创，未经允许，禁止转载！