HTTP（HyperTextTransferProtocol）是超文本传输协议的缩写，它用于传送WWW方式的数据,浏览器与Web服务器之间所遵循的协议就是HTTP，关于HTTP协议的详细内容请参考RFC2616。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户信息和内容的类似于MIME的消息结构。服务器以一个状态行作为响应，相应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。
HTTP协议消息包括Client向Server的请求消息和Server向Client的响应消息。协议消息由起始行，头域和可选的消息体组成。HTTP/1.1是Internet现行的标准协议，这里都以HTTP/1.1为基础介绍。
请求消息的第一行为下面的格式：
Method Request-URI HTTP-Version/r/n
Method表示对于Request-URI完成的方法，这个字段是大小写敏感的，包括OPTIONS、GET、HEAD、POST、PUT、Delete、TRACE。方法GET和HEAD应该被所有的通用WEB服务器支持，其他所有方法的实现是可选的。GET方法取回由Request-URI标识的信息。HEAD方法也是取回由Request-URI标识的信息，只是可以在响应时，不返回消息体。POST方法可以请求服务器接收包含在请求中的实体信息，可以用于提交表单。
Request-URI遵循URI格式，在此字段为星号（*）时，说明请求并不用于某个特定的资源地址，而是用于服务器本身。
HTTP-Version表示支持的HTTP版本，例如为HTTP/1.1。
响应消息的第一行为下面的格式：
HTTP-Version Status-Code Reason-Phrase/r/n
HTTP-Version表示支持的HTTP版本，例如为HTTP/1.1。
Status-Code是一个三个数字的结果代码,主要用于机器自动识别。
Status-Code可能取5个不同的值：
1xx:信息响应类，表示接收到请求并且继续处理
100 继续
101 交换协议
2xx:处理成功响应类，表示动作被成功接收、理解和接受
200 OK
201 已创建
202 接收
203 非认证信息
204 无内容
205 重置内容
206 部分内容
3xx:重定向响应类，为了完成指定的动作，必须接受进一步处理
300 多路选择
301 永久转移
302 暂时转移
303 参见其它
304 未修改（Not Modified）
305 使用代理
4xx:客户端错误，客户请求包含语法错误或者是不能正确执行
400 错误请求（Bad Request）
401 未认证
402 需要付费
403 禁止（Forbidden）
404 未找到（Not Found）
405 方法不允许
406 不接受
407 需要代理认证
408 请求超时
409 冲突
410 失败
411 需要长度
412 条件失败
413 请求实体太大
414 请求URI太长
415 不支持媒体类型
5xx:服务端错误，服务器不能正确执行一个正确的请求
500 服务器内部错误
501 未实现（Not Implemented）
502 网关失败
504 网关超时
505 HTTP版本不支持
Reason-Phrase给Status-Code提供一个简单的文本描述。Reason-Phrase主要用于帮助用户理解。
1. HTTP的头域包括通用头域，请求头域，响应头域和实体头域四个部分。
包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via等方法。
指定请求和响应遵循的缓存机制。缓存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，响应指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。
时间的描述格式由rfc822定义。Date描述的时间表示世界标准时，如Date:Mon,31Dec200104:25:57GMT。
常用的是Pragma:no-cache。在HTTP/1.1协议中，它的含义和Cache-Control:no-cache相同。
2. 请求头域
请求头域允许客户端向服务器传递关于请求或者关于客户机的附加信息。请求头域可能包含下列字段Accept、Accept-Charset、Accept-Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。对请求头域的扩展要求通讯双方都支持，如果存在不支持的请求头域，一般将会作为实体头域处理。
3. Host头域
Host头域指定请求资源的Intenet主机和端口号（默认端口可以省略），必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须包含主机头域，否则系统会以400状态码返回。
4. Referer头域
Referer头域允许客户端指定请求uri的源资源地址，这可以允许服务器生成回退链表，可用来登陆、优化cache等。他也允许废除的或错误的连接由于维护的目的被追踪。如果请求的uri没有自己的uri地址，Referer不能被发送。如果指定的是部分uri地址，则此地址应该是一个相对地址。
5. Range头域
Range头域可以请求实体的一个或者多个子范围。
表示头500个字节：bytes=0-499
表示第二个500字节：bytes=500-999
表示最后500个字节：bytes=-500
表示500字节以后的范围：bytes=500-
第一个和最后一个字节：bytes=0-0,-1
同时指定几个范围：bytes=500-600,601-999
但是服务器可以忽略此请求头，如果无条件GET包含Range请求头，响应会以状态码206 PartialContent）返回而不是以200（OK）。
6. User-Agent头域
User-Agent头域的内容包含发出请求的用户信息，一般是客户机的浏览器类型。
典型的请求消息如下：
GET
http://www.wantsoft.com//r/n
Host:www.wantsoft.com
Accept:*/*
Pragma:no-cache
Cache-Control:no-cache
Referer:www.wantsoft.com
User-Agent:Mozilla/4.04[en](Win95;I;Nav)
Range:bytes=554554-
响应头域允许服务器传递不能放在状态行的附加信息，这些域主要描述服务器的信息和进一步的信息。响应头域包含Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-Authenticate。对响应头域的扩展要求通讯双方都支持，如果存在不支持的响应头域，一般将会作为实体头域处理。
典型的响应消息：
HTTP/1.0200OK
Date:Mon,31Dec200104:25:57GMT
Server:Apache/1.3.14(Unix)
Content-type:text/html
Last-modified:Tue,17Apr200106:46:28GMT
Etag:"a030f020ac7c01:1e9f"
Content-length:39725426
Content-range:bytes554554-40279979/40279980
7. Location响应头域
Location响应头用于重定向接收者到一个新URI地址。
8. Server响应头域
Server响应头域包含处理请求的原始服务器的软件信息。此域能包含多个产品标识和注释，产品标识一般按照重要性排序。
9. Content-Type实体头域
用于向接收方指示实体的介质类型，指定HEAD方法送到接收方的实体介质类型，或GET方法发送的请求介质类型为数据设定称为“MIME-TYPE”的内容类型。MIME，即多任务因特网邮件扩充（Multipurpose Internet Mail Extension），一些常见的内容类型如下：
text/html：HTML文档。
text/plain：纯文本文件。
image/jpeg：jpeg图像文件。
image/GIF：gif图像文件。
image/TIFF：TIFF格式的图形文件。
application/rtf：多信息文本格式文档。
application/zip：PKZIP或WinZIP压缩文件。
video/mpeg：mpeg视频文件。
video/quicktime：QuickTime视频文件。
10. Content-Range实体头用于指定整个实体中的一部分的插入位置，他也指示了整个实体的长度。在服务器向客户返回一个部分响应，它必须描述响应覆盖的范围和整个实体长度。一般格式：
Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth
例如，传送头500个字节次字段的形式：Content-Range:bytes0-499/1234如果一个http消息包含此节（例如，对范围请求的响应或对一系列范围的重叠请求），Content-Range表示传送的范围，Content-Length表示实际传送的字节数。
11. Last-modified实体头
指定服务器上保存内容的最后修订时间。
TCP/IP是互联网的核心协议，也是大多数网络应用的核心协议。就前面一段时间面试中问到的TCP/IP问题，这里给出一个简单的小结。
TCP由RFC793、RFC1122、RFC1323、RFC2001、RFC2018以及RFC2581定义。
(1) TCP概述
a. TCP提供的是面向连接的全双工服务。
TCP所有的数据会匹配到由源地址，目的地址，源端口，目的端口构成的一个TCP连接之上。TCP连接是一种需要建立的资源，可以通过之后会讲到的握手机制来完成。UDP是一种基于尽力而为机制的协议，不存在UDP连接资源的建立，资源的处理往往由应用层协议代劳了。
b. TCP是提供的可靠服务。
TCP有确认机制来保证数据包的可靠到达，
TCP有CRC校验机制来保证数据包的无差错性，UDP的CRC是可选的，
TCP会重新排序乱序的数据包和丢弃重复的数据，
TCP能够提供流量控制机制，使用滑动窗口算法，
TCP能提供拥塞控制与恢复机制，存在多种TCP拥塞控制模型，
TCP能协商发送的数据报文长度。
TCP报头。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCP Header Format
对于TCP头的标记位，SYN标记只在三次握手(或四次握手)的时候的被置位，ACK标记会在握手之后所有的TCP报文中被置位。当然也有一些特殊情况，比如有些情况下RST报文不会置位ACK。
这些规则也许在配置复杂的ACL中有用。
(2) TCP协议栈的状态机 (摘自RFC793)
a. TCP连接的建立。TCP连接的建立有主动打开，被动打开以及同时打开三种情况。
三次握手比较清楚，要强调的是ISN，就是初始序列号的选择问题，序列号是32位的，针对不同的OS，初始序列号的选择往往也是有规律的。
TCP传输的最大报文长度也是在三次握手中协商的。具体说是在也仅在SYN报文中协商的。MSS = MTU - ip_header_len - tcp_header_len。MSS这里也是为了防止分片，提高网络带宽利用率。
TCP三次握手中，最后一个报文ACK，不需要再有额外的确认机制，如果这个ACK在网络中丢弃了，TCP协议栈也有其他的机制来处理。
除了三次握手，还有一种很特殊的应用情况，就是TCP两端同时打开的情况(发送syn)，这种情况没有描述在上面的状态机中。
举例子来说，A通过源端口7777发起到B的目的端口8888的连接的同时，B也通过源端口8888发起对A的目的端口7777的TCP连接。
b. TCP连接的关闭
TCP连接的关闭也有主动关闭，被动关闭和同时关闭三种情况，这三种情况在上面的TCP状态机中都有描述。
TCP连接的关闭需要报文四次交互，因为TCP是一个全双工的服务，所以每个方向的连接都关闭后，TCP的连接才是完整的拆除。
状态机中，主动关闭和同时关闭最后都会进入到一个TIME_WAITE状态。针对TCP主动关闭的最后一个报文应该是ACK，确认对端的FIN报文。这个状态的概念是该TCP连接的资源并没有完全释放，因为还要确保最后一个ACK报文能够无误的到达对端，确认对端的FIN，否则就仍然要重传ACK。
这个等待的过程(或者资源没有完全释放的过程)需要等待2MSL时间(考虑报文一次往返)。MSL是最大报文生存时间，RFC793中为2分钟，根据不同的TCP实现，一般是30s或者1分钟。
所以在TIME_WAITE状态内，该TCP连接所使用的端口和连接资源，不能被继续使用。但是很多TCP实现并没有这个限制，只要新的TCP连接所使用的ISN大于TIME_WAITE状态TCP连接所使用的最后序号即可。实现中往往使用
new ISN = latest ISN in time_waite + 128000
IP报文的最大生存时间是TTL值，TCP报文的最大生存时间是MSL，二层上没有报文最大生存时间的概念，存在风暴的可能。
TCP(Transmission Control Protocol) 传输控制协议
TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接:
位码即tcp标志位,有6种标示:SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)
Sequence number(顺序号码) Acknowledge number(确认号码)
第一次握手：主机A发送位码为syn＝1,随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；
第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包
第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1则连接建立成功。
完成三次握手，主机A与主机B开始传送数据。
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。
第一次握手：建立连接时，客户端发送syn包(syn=1,有初始的Seq Number)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN，给出ACK（Ack Number=发送包的Seq Numebr+1, ACK=1），同时自己也发送一个SYN包（syn=1, 有服务端自己本身的Seq Numebr），即SYN+ACK包，此时服务器进入SYN_RECV状态； 第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。 完成三次握手，客户端与服务器开始传送数据.
实例:
IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836:3626544836
IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486:1739326486 ack 3626544837
IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1
第一次握手：192.168.1.116发送位码syn＝1,随机产生seq number=3626544836的数据包到192.168.1.123,192.168.1.123由SYN=1知道192.168.1.116要求建立联机;
第二次握手：192.168.1.123收到请求后要确认联机信息，向192.168.1.116发送ack number=3626544837,syn=1,ack=1,随机产生seq=1739326486的包;
第三次握手：192.168.1.116收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，192.168.1.116会再发送ack number=1739326487,ack=1，192.168.1.123收到后确认seq=seq+1,ack=1则连接建立成功。
图解：
一个三次握手的过程（图1，图2）
（图1）
（图2）
第一次握手的标志位（图3）
我们可以看到标志位里面只有个同步位，也就是在做请求(SYN)
（图3）
第二次握手的标志位（图4）
我们可以看到标志位里面有个确认位和同步位，也就是在做应答(SYN + ACK)
（图4）
第三次握手的标志位（图5）
我们可以看到标志位里面只有个确认位，也就是再做再次确认(ACK)
（图5）
一个完整的三次握手也就是 请求---应答---再次确认
(3) TCP的滑动窗和定时器
什么是滑动窗口协议？ 首先RWND:接收端通知窗口，CWND: 拥塞窗口
一图胜千言，看下面的图。简单解释下，发送和接受方都会维护一个数据帧的序列，这个序列被称作窗口。发送方的窗口大小由接受方确定，目的在于控制发送速度，以免接受方的缓存不够大，而导致溢出，同时控制流量也可以避免网络拥塞。下面图中的4,5,6号数据帧已经被发送出去，但是未收到关联的ACK，7,8,9帧则是等待发送。可以看出发送端的窗口大小(RWND)为6，这是由接受端告知的（事实上必须考虑拥塞窗口cwnd，这里暂且考虑cwnd>rwnd）。此时如果发送端收到4号ACK，则窗口的左边缘向右收缩，窗口的右边缘则向右扩展，此时窗口就向前“滑动了”，即数据帧10也可以被发送。
a. TCP的报文确认机制。
TCP使用的是滑动窗口机制来发送数据流，所以TCP协议允许连续发送多个TCP分组而不等待对端的确认。
所以发送的分组数据和确认不是一对一的关系。
TCP中，对数据的确认往往是延迟的，一般情况是两个TCP数据对应一个确认，在时延定时器没有溢出的情况下。如果时延定时器溢出了，那么自然也会发送确认报文。
但是，针对存在交互大量微小报文的TCP应用，过于频繁的确认会导致网络利用率的低效，所以TCP支持一种Nagle算法。
b. 延时定时器
当TCP收到报文时候，启动延时定时器，比如200ms。
c. Nagle算法
TCP连接上只能存在一个未被确认的微小报文(41字节的TCP报文)，在该确认到达前，TCP仅仅收集微小报文，当确认到达后，以一个分组的形式发出去。
当然，某些应用需要关闭Nagle算法。
d.滑动窗口机制
e. 重传定时器
目的是为了获得对端的确认报文。如果多次重传仍然没有获得确认，则会发送复位报文RST。
这里我们再来看一下TCP的三次握手。
A(发起端) ---> syn ---> B(服务器)
A(发起端) <--- syn/ack <--- B(服务器)
如果TCP客户端A的最后一个ACK丢失了，TCP服务器B没有收到，会是一种什么情况？
这个时候A已经进入到了Establish状态，然而B还只是Syn_Recev状态，所以服务器会重传syn/ack报文，只到连接的最终建立。但是客户端A已经到建立状态了，所以A是有可能发送TCP数据给服务器B的。
所以TCP的两端，最终状态机是有可能不一致的。
后面会详细讲述重传和拥塞控制机制。
f. 坚持定时器
由于TCP没有对ACK的确认机制，所以当接收端窗口从0恢复到一定值的时候，如果接收端发给发送端的ACK报文(标识窗口大小)丢失了，发送端就永远不知道接收端的窗口恢复情况了。
所以发送端会定时发送带一个字节的ACK给接收端，查看接收端的确认报文中的窗口信息。
g. 保活定时器
由于物理原因，处于IDLE状态的TCP连接一端崩溃的时候，TCP有保活机制来判断对端是否仍然工作。这个设计存在争议，也许应用层应该实现该功能。RFC1122中有描述，保活定时器默认是关闭的。下面截取了一些RFC描述。
Implementors MAY include "keep-alives" in their TCP implementations, although this practice is not universally accepted. If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection, and they MUST default to off.
(4) TCP拥塞控制算法：慢启动、拥塞避免、快速重传和快速恢复
针对拥塞控制，主要有四种模型，即TCP TAHOE，TCP RENO，TCP NEWRENO和TCP SACK。TCP TAHOE模型是最早的TCP协议之一，它由Jacobson提出。
Jacobson观察到，TCP报文段（TCP Segment）丢失有两种原因，其一是报文段损坏，其二是网络阻塞，而当时的网络主要是有线网络，不易出现报文段损坏的情况，网络阻塞为报文段丢失的主要原因。针对这种情况，TCP TAHOE对原有协议进行了性能优化，其特点是，在正常情况下，通过重传计时器是否超时和是否收到重复确认信息（dupack）这两种丢包监测机制来判断是否发生丢包，以启动拥塞控制策略；
在拥塞控制的情况下，采用慢速启动（Slow Start）算法和“拥塞避免”（Congestion Avoidance）算法来控制传输速率。 1990年出现的TCP Reno版本增加了“快速重传 ”（Fast Retransmit）、“快速恢复”（Fast Recovery）算法，避免了网络拥塞不严重时采用“慢启动”算法而造成过度减小发送窗口尺寸的现象，这样TCP的拥塞控制就主要由这4个核心算法组成。
a. 超时与重传
RTT的计算与RTO的计算
b. 慢启动和拥塞避免算法
拥塞控制的对象？
拥塞的原因是负载过大，控制的对象自然是发送者的流量，TCP中用于控制流量的是滑动窗口协议。窗口的大小取决于对端通告的接收窗口(rwnd)和拥塞控制窗口(CWND)，即真正的发送窗口=min(rwnd, cwnd)
慢启动？
最初的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 = 4*2 = 8
如果带宽为W，那么经过RTT*log2W时间就可以占满带宽
拥塞避免?
从慢启动可以看到，cwnd可以很快的增长上来，从而最大程度利用网络带宽资源，但是cwnd不能一直这样无限增长下去，一定需要某个限制。TCP使用了一个叫慢启动门限(ssthresh)的变量，当cwnd超过该值后，慢启动过程结束，进入拥塞避免阶段。对于大多数TCP实现来说，ssthresh的值是 65536(同样以字节计算)。拥塞避免的主要思想是加法增大，也就是cwnd的值不再指数级往上升，开始加法增加。此时当窗口中所有的报文段都被确认时，cwnd的大小加1，cwnd的值就随着RTT开始线性增加，这样就可以避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。
拥塞避免算法其实是和慢启动配合使用的。cwnd和ssthresh都是动态的值，虽然初始值为1和65535。
当真正拥塞发生的时候，如果是超时或重复ack引起的拥塞，ssthreash会置为cwnd和接收窗口大小的一半，cwnd会降为1，然后执行慢启动算法，直到cwnd大于ssthresh的时候，执行拥塞避免算法；
在慢启动算法期间和拥塞避免算法期间，TCP的发送速率都是在增长的，只是一个是指数增长方式，一个是线性增长方式。
如何检测拥塞？
首先来看TCP是如何确定网络进入了拥塞状态的，TCP认为网络拥塞的主要依据是它重传了一个报文段。上面提到过，TCP对每一个报文段都有一个定时器，称为重传定时器(RTO)，当RTO超时且还没有得到数据确认，那么TCP就会对该报文段进行重传，当发生超时时，那么出现拥塞的可能性就很大，某个报文段可能在网络中某处丢失，并且后续的报文段也没有了消息，在这种情况下，TCP反应比较“强烈”：
1.把ssthresh降低为cwnd值的一半
2.把cwnd重新设置为1
3.重新进入慢启动过程。
从整体上来讲，TCP拥塞控制窗口变化的原则是AIMD原则，即加法增大、乘法减小。可以看出TCP的该原则可以较好地保证流之间的公平性，因为一旦出现丢包，那么立即减半退避，可以给其他新建的流留有足够的空间，从而保证整个的公平性。
c . 快速重传和快速恢复算法
TCP连接中有两种情况会引起重复的ack，一种是乱序报文，一种是丢包。
快速重传：当发送方收到三个重复的ack后，不会进入慢启动状态，而是立刻重传丢失的报文。因为只有接收方收到新的报文段的时候，才会发送重复的ack，这表明TCP连接上仍然有数据流动，所以应该避免使用慢启动降速。
快速恢复：
第一步，当收到第三个重复的ack的时候，ssthresh设置为当前cwnd的一半，重传丢失的报文。设置cwnd为ssthresh加上3倍的报文段大小(cwnd=cwnd/2 + 3)。
第二步，每收到一个重复的ack，cwnd增加1并发送一个分组。
第三步，当下一个确认新数据的ack到达的时候，设置cwnd为上面第一步中ssthresh值，这个ack应该是对重传报文的确认，同时也是对丢包后面的中间报文的确认。
最后，在收到三个重复ack的情况下，速度减半。
快速重传算法首次出现在4.3BSD的Tahoe版本，快速恢复首次出现在4.3BSD的Reno版本，也称之为Reno版的TCP拥塞控制算法。
可以看出Reno的快速重传算法是针对一个包的重传情况的，然而在实际中，一个重传超时可能导致许多的数据包的重传，因此当多个数据包从一个数据窗口中丢失时并且触发快速重传和快速恢复算法时，问题就产生了。因此NewReno出现了，它在Reno快速恢复的基础上稍加了修改，可以恢复一个窗口内多个包丢失的情况。具体来讲就是：Reno在收到一个新的数据的ACK时就退出了快速恢复状态了，而NewReno需要收到该窗口内所有数据包的确认后才会退出快速恢复状态，从而更一步提高吞吐量。
SACK就是改变TCP的确认机制，最初的TCP只确认当前已连续收到的数据，SACK则把乱序等信息会全部告诉对方，从而减少数据发送方重传的盲目性。比如说序号1，2，3，5，7的数据收到了，那么普通的ACK只会确认序列号4，而SACK会把当前的5，7已经收到的信息在SACK选项里面告知对端，从而提高性能，当使用SACK的时候，NewReno算法可以不使用，因为SACK本身携带的信息就可以使得发送方有足够的信息来知道需要重传哪些包，而不需要重传哪些包。
(5) TCP的应用
前几天和公司做防火墙限速的同事聊天, 我们公司新的防火墙限速实现方案就用到了TCP窗口机制. 作所周知, QoS除了分类，测速，队列还有调度一类的借助硬件的算法以外，在基于缓存或者丢包的限速基础上，最好还要降低TCP端到端的真正发送的速率，否则容易引起TCP的一系列拥塞控制动作。我们软件新的设计，就是通过修改ACK方向的通告窗口大小，来控制发送发的速率，能够在限速的基础上，同时降低发送方的发送速率。
先来一个讲TCP、UDP和HTTP关系的
1、TCP/IP是个协议组，可分为三个层次：网络层、传输层和应用层。
在网络层有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议。
在传输层中有TCP协议与UDP协议。
在应用层有FTP、HTTP、TELNET、SMTP、DNS等协议。
因此，HTTP本身就是一个协议，是从Web服务器传输超文本到本地浏览器的传送协议。
2、HTTP协议是建立在请求/响应模型上的。首先由客户建立一条与服务器的TCP链接，并发送一个请求到服务器，请求中包含请求方法、URI、协议版本以及相关的MIME样式的消息。服务器响应一个状态行，包含消息的协议版本、一个成功和失败码以及相关的MIME式样的消息。
HTTP/1.0为每一次HTTP的请求/响应建立一条新的TCP链接，因此一个包含HTML内容和图片的页面将需要建立多次的短期的TCP链接。一次TCP链接的建立将需要3次握手。
另外，为了获得适当的传输速度，则需要TCP花费额外的回路链接时间（RTT）。每一次链接的建立需要这种经常性的开销，而其并不带有实际有用的数据，只是保证链接的可靠性，因此HTTP/1.1提出了可持续链接的实现方法。HTTP/1.1将只建立一次TCP的链接而重复地使用它传输一系列的请求/响应消息，因此减少了链接建立的次数和经常性的链接开销。
3、结论：虽然HTTP本身是一个协议，但其最终还是基于TCP的。不过，目前，有人正在研究基于TCP+UDP混合的HTTP协议。
Socket是什么呢？
Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。
参考http://jasonccie.blog.51cto.com/2143955/422966
http://www.cnblogs.com/rootq/articles/1377355.html
http://www.cnblogs.com/ulihj/archive/2011/01/06/1927662.html
本文深入解析HTTP协议的工作原理，涵盖请求与响应模型、状态码、头部字段等内容，并详细阐述TCP协议的关键特性，包括连接建立与关闭流程、滑动窗口机制、拥塞控制算法等。
扫一扫
3万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
