目录
1、Http报文
HTTP请求报文由请求行、请求头部、空行和请求包体4个部分组成，如下图所示：
1.1、通用报文
General:
//通用报文
-
Request URL: http://www.cnblogs.com/favicon.ico
-
Request Method: GET
-
Status Code: 200 OK
-
Remote Address: 47.111.45.248:80
-
Referrer Policy: origin
1.2、请求报文
Request Headers:
//客户端请求头
-
Accept : image/webp,image/apng,image/*,*/*;q=0. //浏览器客户端告诉告诉服务端能接受什么样类型的数据
-
Accept-Encoding: gzip, deflate //浏览器客户端告诉服务器能接受什么编码格式，包括字符编码，压缩方式
-
Accept-Language: zh-CN,zh;q=0.9 //客户端告诉浏览器接受什么样的语言
-
Accept-Ranges: bytes //断点续传
-
ETag: "23411b8a827d31:0”. //304
-
Cache-Control : no-cache
-
Connection : keep-alive //客户端告诉服务端的连接方式： 长连接
-
X-UA-Compatible: IE=10
-
X-Frame-Options: SAMEORIGIN
-
Cookie: _ga=GA1.2.1796862747.1547952793; __gads=ID=60d16307ea494dae:T=1547952794:S=ALNI_MYsoIBtEfg7-PJNMTds68JgtxnQrw; UM_distinctid=168832d7c157de-0ad85a26ff65a-35617601-13c680-168832d7c168b3;
-
Host: www.cnblogs.com。 //要请求的主机及端口 目的地
-
Pragma: no-cache
-
Referer: http://www.cnblogs.com/ //客户端告诉浏览器这个请求是从那里过来的，请求来源
-
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36。 //浏览器指定，告诉服务器，使用的浏览器的版本和名称自动发送
1.3、响应报文
Response Headers:
//服务器返回http头
-
HTTP/1.1 200 OK
-
Date: Tue, 16 Apr 2019 05:13:48 GMT //什么时候响应会浏览器
-
Content-Type : image/x-icon。 //响应的内容是什么类型，采用的是什么编码， 对应请求的accept设置内容
-
Content-Length : 1332 //服务端告诉浏览器相应实体的大小
-
Connection: keep-alive ／close //服务端告诉浏览器连接的方式为长连接， 管道连接，异步响应http的请求，http1.1，提高效率；
-
Cache-Control : max-age=120. //服务端告诉浏览器缓存的时间最长为120s
-
Last-Modified : Fri, 28 Jul 2017 09:18:56 GMT //服务器文本最后一次修改的时间. 304
ps：在实际情况中使用：
response.setContentType("text/html;charset=UTF-8”); 来设置编码以解决中文的乱码问题。
（0）、Connection: keep-alive ／close 服务端告诉浏览器连接的方式为长连接，
管道连接，异步响应http的请求，http1.1，提高效率；
（1）、MIME Type:是描述消息内容类型的因特网标准，
常见的数据几种类型
-
文本文件:text/html,text/plain,text/css,application/xhtml+xml,application/xml
-
图片文件:image/jpeg,image/gif,image/png.
-
视频文件:video/mpeg,video/quicktime
我们可以通过两种方式来设置文件的渲染类型，
-
第一种是 Accept-客户端
-
第二种是 Content-Type-服务器
Accept
: 表示
客户端希望接受的数据类型，即告诉服务器我需要什么媒体类型的数据，此时 服务器应该根据 Accept 请求头生产指定媒体类型的数据。
Content-Type
: 表示发送端发送的实体数据类型，比如我们应该写过类似的: resposne.setContentType(“application/json;charset=utf-8”)的代码，表示服务端返回的数据 格式是 json。
如果 Accept 和 Content-Type 不一致，假如说 Accept 要接收的类型是 image/gif，但是服务 端返回的数据是 text/html，那么浏览器将会无法解析。
（2）
.Cache-Control 作用：
客户端浏览器用来判断是否需要用本地缓存。
默认值为private；常用值有private、no-cache、max-age、must-revalidate。
具体场景举例：
a.打开新窗口时值为
private、no-cache、must-revalidate
，那么打开新窗口访问时都会重新访问服务器。
而如果指定了
max-age 和 expire 值（单位为秒），那么在此值内的时间里就不会重新访问服务器：
例如：Cache-control: max-age=5(表示当访问此网页后的5秒内再次访问不会去服务器)
b.在地址栏回车
-
值为 private或must-revalidate则只有第一次访问时会访问服务器，以后就不再访问。
-
值为 no-cache，那么每次都会访问。
-
值为 max-age 和 expire，则在过期之前不会重复访问。
c.按后退按扭
-
值为private、must-revalidate、max-age，则不会重访问，
-
值为no-cache，则每次都重复访问
d.按刷新按扭
-
无论为何值，都会重复访问；
（3）
、Cookie 作用：客户端浏览器用来存储一些用户信息以便让服务器辨别用户身份的（大多数需要登录的网站上面会比较常见），比如用户名和密码，sessionId等。
（4）
、If-Modify-Since 作用：
把浏览器端缓存页面的最后修改时间（精确到秒）发送到服务器去，服务器会把这个时间与服务器上实际文件的最后修改时间进行对比。如果时间一致，那么返回304，客户端就直接使用本地缓存文件。如果时间不一致，就会返回200和新的文件内容以及新的修改时间(Last-Modify)。客户端接到之后，会丢弃旧文件，把新文件缓存起来，并显示在浏览器中。
（5）
、Etag的使用场景：
1.有些文件需要频繁更新，但是文件内容并没有变化。
聪明的开发者会把
Last-Modified和ETags请求的http报头一起使用，提高浏览器性能。这样可利用客户端（例如浏览器）的缓存。因为服务器首先产生Last-Modified/Etag标记，服务器可在稍后使用它来判断页面是否已经被修改。本质上，客户端通过将该记号传回服务器要求服务器验证其（客户端）缓存。
过程如下:
-
1.客户端请求一个页面（A）。
-
2.服务器返回页面A，并在给A加上一个Last-Modified/ETag。
-
3.客户端展现该页面，并将页面连同Last-Modified/ETag一起缓存。
-
4.客户再次请求页面A，并将上次请求时服务器返回的Last-Modified/ETag一起传递给服务器。
-
5.服务器检查该Last-Modified或ETag，并判断出该页面自上次客户端请求之后还未被修改，直接返回响应304和一个空的响应体。
（6）
、如果服务器又设置了Cache-Control:max-age和Expires呢，怎么办？
答案是同时使用，也就是说在完全匹配If-Modified-Since和If-None-Match即检查完修改时间和Etag之后，服务器才能返回304.(不要陷入到底使用谁的问题怪圈)
（7）
、如果传输的文件很大怎么办？
-
方案一：通过压缩文件： Accept-Encoding: gzip , deflate ;
-
方案二：分割传输，浏览器逐步显示；
2、状态码
1XX ： 接受的请求正在处理
200: 请求正常处理
3xx开头，资源文件
-
301: 资源被永久删除，永久重定向到新的网址
-
302: 旧的资源还在，只是暂时性的重定向资源
-
重定向原因：
-
（1）网站调整（如改变网页目录结构）；
-
（2）网页被移到一个新地址；
-
（3）网页扩展名改变(如应用需要把.php改成.Html或.shtml)。
-
304: 返回上次请求资源未作改动,验证浏览器的缓存机制 Etag
-
307: 资源的重定向，但是不会把post改为get操作；
4xx开头：客户端
-
400: 请求参数错误
-
401: 客户端无权访问,要去输入用户名\密码之类的授权信息
-
403: 禁止访问(读写权限等影响)
-
404: 请求的资源不存在
5xx开头：服务端
-
500: 服务内部错误
-
502: 网关错误
-
503: 临时过载或者维护,导致服务端无法正常处理请求
3、拥塞
计算机网络中的带宽，交换节点中的缓存和处理机制，都是网络资源。在某段时间内，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏。这种情况就叫做拥塞。
拥塞发生的主要原因是网络能够提供的资源不足以满足用户的需求，这些资源包括缓存空间、链路带宽容量和中间节点的处理能力。由于互联网的设计机制（任何人任何时间都能共享网络资源）导致其缺乏“接纳控制”能力，因此在网络资源不足时不能限制用户数量，只能靠降低服务质量来继续为用户服务，也就是“尽力而为”服务。但是也不是说增加网路资源，就可以避免网络拥塞。拥塞虽然是由于网络资源的缺乏引起的，
但是单纯增加资源并不能避免拥塞的发生。有时增加缓存空间到一定程度时，只会加重拥塞，而不是减轻拥塞，这是因为当数据包经过长期时间排队完成转发时，他们可能早已经超时，从而引起源端超时重发，，而这些数据包还会继续传输到下一个路由器，从而浪费网络资源，加重网络拥塞。事实上，
缓存空间不足导致的丢包更多的是拥塞的“症状”而非原因。另外，增加链路宽带及提高处理能力也不能解决拥塞问题。
例如我们有4台ABCD主机和一个路由，所有的链路带宽都是1Gbps，如果A和B 同时以1Gbps的速率发送数据，则路由器的输入速率为2Gpbs，从而产生拥塞。避免拥塞的方法是控制AB的发送速率，例如AB都是0.5Gpbs，但是如果此时D也以1Gpbs的速率发送，那么拥塞还是无法避免，况且用户主机不可能只有4个。
所以说拥塞只是一个动态问题，我们没有办法用一个静态方案去解决，从这个意义上说，拥塞时不可避免的！！
拥塞是一个全局控制的过程，他不像点对点的流控机制，是一个局部的控制！
4、TCP的拥塞控制算法
TCP的拥塞控制由4个核心的算法组成：
慢启动（slow start）、拥塞避免（Congestion voidance）、快速重传（Fast Retransmit）和快速恢复（Fast Recovery）。
拥塞控制，在发送方维持着一个拥塞窗口cwmd（congestion window）的状态量。拥塞窗口的大小取决于网络的拥塞程度，并且动态的变化。发送方让自己的发哦送窗口等于拥塞窗口，另外考虑到接收方的接收能力，发送窗口可能小于拥塞窗口。
4.1、慢启动（slow start）
早期的开发的TCP应用在启动一个连接时会向网络中发送大量的数据包，这样很容易导致路由器缓存空间耗尽，网络发生拥塞，使得TCP连接的吞吐量急剧下降。由于TCP源端一开始并不知道网络资源当前的利用状况，因此新建立的TCP连接不能一开始就发送大量的数据，而只能逐步增加每次发送的数据量，以避免上述现象的发生。具体来说，当新建立一个连接时，CWND初始化为1个最大报文段（MSS）大小，发送端开始按照拥塞窗口大小发送数据，每当有一个报文被确认，cwnd就增加1个MSS大小。这样cwnd的值就随着网络往返时间（Round trip time，RTT）呈指数级增长，事实上，慢启动的速度一点也不慢，只是他的起点比较低一点儿而已，指数级的增长率是十分快的。
该算法的思想主要是一种探测一下网路的拥塞程度，就是不要一开始就发送大量的数据，也就是说有小到大逐渐增加（指数）拥塞窗口的大小。
我们可以简单计算：
开始cwnd=1
经过1个RTT后， cwnd=2*1=2
经过2个RTT后， cwnd=2*2=4
经过3个RTT后， cwnd=2*4=8
如果宽带为W，那么经过RTT*log2W时间就可以占满带宽；
4.2、拥塞避免（Congestion voidance）
如果按上述的慢启动的思想如果不加以控制的话，毫无疑问的发生网络拥塞，当cwnd很快增长上来的时候，也很快利用了网络的资源，但是cwnd不能一直这样增长，一定需要某个限制。TCP使用了一个慢启动门限（ssthresh）的变量，当cwnd超过该值后，慢启动结束，进入拥塞避免阶段。对于大多数的TCP是吸纳来说，ssthresh的值是65535（同样以16bit来计算）。拥塞避免的思想就是转指数增大变为加法线性增大。这样就可以避免增长过快导致网路拥塞，慢慢的增加调整到网络的最佳值。
期具体ssthresh的用法如下：
当cwnd<ssthresh时，使用慢开始算法。
当cwnd>ssthresh时，改用拥塞避免算法。
当cwnd=ssthresh时，慢开始与拥塞避免算法任意。
注意：如果当前的cwnd达到慢启动的阈值，则试探性的发送一个segment，如果服务器没有响应，TCP认为网络能力下降，必须降低慢启动阈值，同时为了避免形式继续恶化，有可能将窗口降低为1.
4.3、快速重传（Fast Retransmit）
正常情况下，按照上一节讲的消息重传是等到定时器超时（RTO）后在重传，但有时候不需要等那么久也可以重传。比如客户端向服务器发送了5个段数据包。第三个丢失，其他正常，那么客户端会收到3个包2的ACK，而4、5正常到达后会被服务器缓存起来但是不会发送相应包的ACK，因为TCP是基于积累确认机制，以确保丢失的包能被重发，数据接收准确，ACK必须是连续的。这个时候就不必在等待RTO的超时时间了，服务器判断已经丢失了就可以马上快速重传，提高效率。
快速重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置重传计时器时间到期。
4.4、快速恢复（Fast Recovery）
其实快速恢复并不是单独存在的，它是快速重传的后续处理。通常认为客户端接收到3个ACK后，就会开始快速重传，但是如果还有更多的重复ACK呢，这个时候就是快速恢复要做的。
a、当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半（也即cwnd=ssthresh/2）.但是接下去并不执行慢开始算法；
b、考虑到此时能连续收到3个ACK，说明网络没有拥塞，执行加法原则，有几个ACK就加几个段的字节数，
或者可以将cwnd=ssthresh，直接进入拥塞避免算法。
四种算法相互间的合作运行图如下所示：
5、问题思考
问题一：如何检测拥塞?
首先来看一下TCP是如何确定网络进入拥塞的，TCP认为网络拥塞的主要依据是它重传了一个报文段。上面提到过，TCP对每一个报文段都有一个定时器，称为重传定时器（RTO），当RTO超时且还没有得到数据确认，那么TCP就会对该报文段进行重传，当发生超时时，那么出现拥塞的可能性就很大，某个报文段可能在网络中某处丢失，并且后续的报文段也没有了消息，在这种情况下，TCP反应比较“强烈”：
（1）把ssthresh降低为cwnd值的一半；
（2）把cwnd重新设置为1；
（3）重新进入慢启动过程；
可以看出，从整体上讲，TCP拥塞控制窗口变化的原则是：
AIMD（Additive Increase Multiplicative Decrease）。TCP/IP模型中，属于运输层，即：加性增，乘性减，
或者叫做“和式增加，积式减少”。该原则很好的保证了流之间的公平性，因为一旦出现丢包，那么立即减半退避，可以给其他新建的流留有足够的空间，从而保证整个的公平性。
问题二：为什么客户端没接收到一个ACK，会把cwnd增加一个segment呢?
这是基于管道模型的“数据包守恒”原则，及同一时刻在网络中传输的数据包数量是恒定的，只有当“旧”数据包离开网路后，才能发送“新”数据包进入网络。如果发送方收到一个ACK，则认为有一个数据已经离开了网络，于是将拥塞窗口+1，如果网路能够严格遵守该“数据包守恒”原则，则拥塞的法神会大大减少。
有趣的联想：
TCP拥塞的解决就像是我们生活中的交通堵车？
其中有两个原则：
一、拥塞不可避免，单纯增加资源并不能避免拥塞的发生；
二、数据包守恒原则。如果政府只是花资金修路，拓宽公路，并不能避免堵车，因为车的数量是不定的，旅游季可能有很多，也许一时间段没有车，这时候只能从源头控制。对车流量进行控制：例如限制车辆进入主公路，根据实际的情况，如果某一时间段车辆少，则可以慢慢增加车辆进入该公路段，但是当达到一个 阈值，就要放缓车辆进入的速度，并实时的探测整条路的状况，如果情况紧急，则立刻将车流量减少一半，将车流量降到最低，然后在重新回到慢启动转态。使整条公路能够保持畅通，达到最大的运行效率。
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
