TCP协议
第17章 TCP传输控制协议
17.1 TCP协议格式
TCP将用户数据打包构成报文段，它发送数据后启动一个定时器；另一段对收到的数据进行确认，对失序的数据重新排序，丢弃重复数据；提供端到端的流量控制，并计算和验证一个强制性的端到端检验和。
第18章 TCP连接建立与终止
18.1 TCP建立与终止
MSS: Maxitum Segment Size 最大报文段长度
MSS是TCP数据包每次能够传输的最大数据分段，简单来说就是tcp传往另一端的最大块数据长度。这个值TCP协议在实现的时候往往用MTU值代替（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes）, 通讯双方会根据双方提供的MSS值得最小值确定为这次连接的最大MSS值。以太网MTU都为1500, 所以在以太网中, 往往TCP MSS为1460。
怎么修改MSS：
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN- j TCPMSS --set-mss 128
18.2 TCP状态转换
CLOSED: 这个没什么好说的了，表示初始状态。
LISTEN: 这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了
SYN_RCVD: 这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。
SYN_SENT: 这个状态与SYN_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状 态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。
ESTABLISHED: 这个容易理解了，表示连接已经建立了。
FIN_WAIT_1（重要）: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别 是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。
FIN_WAIT_2（重要）: 上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。
TIME_WAIT（重要、共详细的请看下图的2MSL）: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL（<u>最大报文段生存时间</u><u>：目的是为了</u><u>保证TCP协议的全双工连接能够可靠关闭</u><u>；</u><u>保证这次连接的重复数据段从网络中消失</u>）后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
CLOSING: 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。
LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。
18.2.1 TCP正常建立连接和终止所对应的状态
18.2.2 服务器保持了大量TIME_WAIT状态
TIME_WAIT是主动关闭连接的一方保持的状态，对于爬虫服务器来说他本身就是客户端，在完成一个爬取任务之后，他就会发起主动关闭连接，从而进入TIME_WAIT的状态，然后在保持这个状态2MSL时间之后，彻底关闭回收资源。这是TCP/IP设计者规定的，主要出于以下两个方面的考虑：
（1）防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL，上一次连接中所有的重复包都会消失）
（2）可靠的关闭TCP连接。在主动关闭方发送的最后一个ack(fin)，有可能丢失，这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ，就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。另外这么设计TIME_WAIT 会定时的回收资源，并不会占用很大资源的，除非短时间内接受大量请求或者受到攻击。
对于HTTP的交互跟上面画的那个图是不一样的，关闭连接的不是客户端，而是服务器，所以web服务器也是会出现大量的TIME_WAIT的情况的。
18.2.3 服务器保持了大量CLOSE_WAIT状态
假设一个场景，服务器A是一台爬虫服务器，它使用简单的HttpClient去请求资源服务器B上面的apache获取文件资源，正常情况下，如果请求成功，那么在抓取完资源后，服务器A会主动发出关闭连接的请求，这个时候就是主动关闭连接，服务器A的连接状态我们可以看到是TIME_WAIT。如果一旦发生异常呢？假设请求的资源服务器B上并不存在，那么这个时候就会由服务器B发出关闭连接的请求，服务器A就是被动的关闭了连接，如果服务器A被动关闭连接之后程序员忘了让HttpClient释放连接，那就会造成CLOSE_WAIT的状态了。
CLOSE_WAIT数目过大是由于被动关闭连接处理不当导致的。如果一直保持在CLOSE_WAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。换句话说，就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。个人觉得这种情况，通过服务器内核参数也没办法解决，服务器对于程序抢占的资源没有主动回收的权利，除非终止程序运行。
所以如果将大量CLOSE_WAIT的解决办法总结为一句话那就是：查代码。
18.3 2MSL等待状态
每个具体 TCP实现必须选择一个报文段最大生存时间MSL(Maximum Segment Lifetime)。它是任何报文段被丢弃前在网络内的最长时间。我们知道这个时间是有限的,因为 TCP报文段以IP数据报在网络内传输,而 IP数据报则有限制其生存时间的TTL字段。
当 TCP执行一个主动关闭,并发回最后一个 ACK,该连接必须在 TIME_WAIT状态停留的时间为 2倍的MSL。这样可让 TCP再次发送最后的ACK以防这个ACK丢失(另一端超时并重发最后的 FIN)。
在连接处于 2MSL等待时,任何迟到的报文段将被丢弃。因为处于 2MSL等待的、由该插口对(socket pair)定义的连接在这段时间内不能被再用。
18.4 RST复位报文
RST表示复位，用来异常的关闭连接，在TCP的设计中它是不可或缺的。发送RST包关闭连接时，不必等缓冲区的包都发出去（FIN包），直接就丢弃缓存区的包发送RST包。而接收端收到RST包后，也不必发送ACK包来确认。
TCP处理程序会在自己认为的异常时刻发送RST包。
对于复位报文是异常终止的表现，socket API通过”linger on close”选项（SO_LONGER）提供了这种异常关闭的能力；
当socket在读/写数据时，出现Connection reset by peer错误时，表明该链接被对方复位了。
第19章 TCP的交互数据流
在TCP进行数据传输时，可以分为成块数据流和交互数据流两种，如果按字节计算，成块数据与交互数据的比例约为90%和10%，TCP需要同时处理这两类数据，且处理的算法不同。
下图为没有优化的字符输入回显的数据传输过程，一共需要四个报文段。
解决方案：时延的确认 / Nagle算法
19.1 经受时延的确认
上图第二，三个报文段可以合并一起发送。这种技术叫做经受时延的确认。
通常TCP在接收到数据时并不立即发送ACK，相反，它推迟发送，以便将ACK与需要沿该方向发送的数据一起发送（有时这种现象为数据捎带的ACK）。绝大数实现采用的时延为200ms，也就是说，TCP将以最大200ms的时延等待是否有数据一起发送。
ACK延时等待时间不大于TCP定时器的原因:
假如TCP使用200ms的定时器，该定时器将相对于内核引导的200ms固定时间溢出，由于将要确定的数据随机到达，TCP将在下一次内核的200ms定时器溢出时得到通知，所以ACK实际等待的时间为1~200ms中任一刻。
19.2 Nagle算法
Nagle算法要求TCP连接上最多只有一个未被确认的未完成小分组，在该分组确认到达之前不能发送其他的小分组。相反，TCP收集这些少量的分组，并在确认到达时以一个大的分组发出去。
算法的大致思路如下：应用程序把要发送的数据逐个字节地送到TCP的发送缓存，发送方把前面的一部分数据先发送出去，并把后面到达的数据继续缓存起来，当发送方收到前面字节的确认后，再把发送缓冲中的所有数据组装成一个报文段发送出去，同时继续对随后到来的数据进行缓存。只有收到前一个报文段的确认后才能继续发送下一个报文段。另外，Nagle算法还规定，当发送缓存中的数据已达到发送窗口大小的一半或已达到报文段的MSS值时，就立即发送一个报文段。
该算法的优点在于它是自适应的：确认到达得越快，数据也就发送得越快。可以减少网络上的微小分组数目，降低拥塞出现的可能（局域网这些小分组通常不会引起麻烦，但在较慢的广域网则存在拥塞的可能）。但相应的，因为不是立即ACK，也会增加更多的时延。
有时我们也需要关闭 Nagle算法。一个典型的例子是 X窗口系统服务器:小消息(鼠标移动)必须无时延地发送,以便为进行某种操作的交互用户提供实时的反馈。
第20章 TCP的成块数据流
20.1 隔一个报文段确认策略
TCP处理一个接收的报文将产生一个经受时延的确定，此ACK并不立即返回，这时分两种情况（隔一个报文或者定时器溢出）：
(1)TCP处理下一个报文，然后返回一个ACK确定2个报文段(可以想象成捎带ACK)。
(2)定时器溢出，返回ACK。如果溢出时，TCP接收缓冲区中还有数据没有被应用层读取完，那么返回报文段的窗口值将为初始窗口值减去缓冲区中的值。
20.2 滑动窗口协议
1）称窗口左边沿向右边沿靠近为窗口合拢。这种现象发生在数据被发送和确认时。
2）当窗口右边沿向右移动时将允许发送更多的数据,我们称之为窗口张开。这种现象发生在另一端的接收进程读取已经确认的数据并释放了 TCP的接收缓存时。
3）当右边沿向左移动时,我们称之为窗口收缩。 Host Requirements RFC强烈建议不要使用这种方式。但 TCP必须能够在某一端产生这种情况时进行处理。
20.3 慢启动
该算法通过观察到新分组进入网络的速率应该与另一端返回确认的速率相同而进行工作
慢启动为发送方的 TCP增加了另一个窗口：拥塞窗口，记为cwnd。发送方开始时发送一个报文段，然后等待 ACK。当收到该 ACK时，拥塞窗口从 1增加为2，即可以发送两个报文段。当收到这两个报文段的 ACK时，拥塞窗口就增加为 4。这是一种指数增加的关系。在某些点上可能达到了互联网的容量，于是中间路由器开始丢弃分组。
20.4 拥塞窗口（cwnd）原理：
1）发送方开始发送一个报文，然后等待ACK。
2）当收到该ACK时，拥塞窗口从1增加到2，即可以发送2个报文段。
2）发送方再发送2个报文段，然后等待ACK，当收到这两个报文段的ACK时，拥塞窗口就增加为4。这是一种指数增加的关系。
如此循环.....
在某些点上可能达到了互联网的容量，于是中间路由器开始丢弃分组，这就通知发送方它的拥塞窗口开得过大。
慢启动算法用于保证新分组进入网络的速率与另一端返回确定的速率相等。
拥塞窗口是发送使用的流量控制；通告窗口是接收方使用的流量控制。
第21章 TCP的超时重传
TCP提供可靠的运输层。它使用的方法之一就是确认从另一端收到的数据。但数据和确认都有可能会丢失。TCP通过在发送时设置一个定时器来解决这种问题。如果当定时器溢出时还没有收到确认，它就重传该数据。
对于实现而言，关键之处就在于超时和重传的策略，即怎样决定超时间隔和如何确定重传频率。
TCP管理4种不同的定时器：
· 重传定时器：当希望收到另一端的确认时使用。
· 坚持定时器：使窗口信息保持不断流动，即使另一端关闭了其接收窗口。
· 保活定时器：检测一个空闲连接的另一端何时崩溃或重启。
· 2MSL定时器：测量一个连接处于TIME_WATI状态的时间。
指数退避****：检查连续重传之间不同的时间差，它们取整后分别是1、3、6、12、24、48和多个64秒，其中第一次发送后设置的超时时间设置为1.5秒。（2的N次方*1.5秒）
21.1 往返时间测量
RTT(往返时间)：指发送端发送TCP报文段开始到接收到对方的确定所使用的时间。
RTO(超时重传时间)：发送端发送TCP报文段后，在RTO时间内没有收到对方确定，即重传该报文段。
TCP超时与重传中最重要的部分就是对一个给定连接的往返时间的测试。由于路由器和网络流量均会变化，因此我们认为这个时间可能经常会发生变化，TCP应该跟踪这些变化并相应地改变其超时时间。因此RTO值基于RTT的均值和方差，这更好的响应了RTT的变化（具体公式见书本）。
21.2 karn算法
重传多义性：假如发送一个分组，当发生超时，RTO指数退避，重传该分组，然后收到ACK。此时但并不能确定这个ACK是针对第一个分组还是重传分组，这就是重传多义性问题。
karn算法针对这个问题
(1)对于超时重传的数据报的确认，不更新RTT。
(2)要注意的是：重传的情况下，RTO不用上面的公式计算，而采用一种叫做“指数退避”的方式。RTO指数退避，下一次传送就使用这个RTO值。
(3)重传数据确认之后，再次发送的数据如果正常被确定，恢复Jacobson 1988公式，更新RTO和RTT。
21.3 拥塞避免算法
该算法假定由于分组受到损坏引起的丢失是非常少的，因此分组丢失就意味着源主机和目的主机之间的某处网络上发生了拥塞。有两种分组丢失的指示：
Ø 发生超时
Ø 接收到重复的确认
数据在传输的时候不能只使用一个窗口协议，我们还需要有一个拥塞窗口来控制数据的流量，使得数据不会一下子都跑到网路中引起“拥塞”。也曾经提到过，拥塞窗口最初使用指数增长的速度来增加自身的窗口，直到发生超时重传，再进行一次微调。但是没有提到，如何进行微调，拥塞避免算法和慢启动门限就是为此而生。
所谓的慢启动门限就是说，当拥塞窗口超过这个门限的时候，就使用拥塞避免算法，而在门限以内就采用慢启动算法。所以这个标准才叫做门限。通常，拥塞窗口记做cwnd，慢启动门限记做ssthresh。下面我们来看看拥塞避免和慢启动是怎么一起工作的。
拥塞避免算法和慢启动算法是两个目的不同、独立的算法。我们希望降低分组进入网络的传输速率，于是可以调用慢启动来作到这一点，拥塞避免算法和慢启动算法通常一起使用：
每个连接维持两个变量: 拥塞窗口( cwnd ) 慢启动门限( ssthresh )[下图中假设为16]；
算法概要：
1).对一个给定的连接，初始化cwnd为1个报文段，ssthresh为65535个字节。
2).TCP输出例程的输出不能超过cwnd和接收方通告窗口的大小。拥塞避免是发送方使用的流量控制，而通告窗口则是接收方进行的流量控制。前者是发送方感受到的网络拥塞的估计，而后者则与接收方在该连接上的可用缓存大小有关。
3).当拥塞发生时（超时或收到重复确认），ssthresh被设置为当前窗口大小的一半[下图中的12]（cwnd 和接收方通告窗口大小的最小值，但最少为2个报文段）。此外，如果是超时引起了拥塞，则 cwnd被设置为1个报文段（这就是慢启动）。
4).当新的数据被对方确认时，就增加cwnd，但增加的方法依赖于我们是否正在进行慢启动或拥塞避免。如果cwnd小于或等于ssthresh，则正在进行慢启动，否则正在进行拥塞避免。 慢启动一直持续到我们回到当拥塞发生时所处位置的半时候才停止（因为我们记录了在步骤2 中给我们制造麻烦的窗口大小的一半），然后转为执行拥塞避免。
cwnd增加方式:
慢启动初始cwnd为1，每收到一个确定就加1，成指数增长。
拥塞避免算法在每个RTT内增加 1/cwnd 个报文，成线性增长。
慢启动根据收到的ACK次数增加cwnd，而拥塞避免算法在一个RTT不管收有多少ACK也只增加一次。
21.4 快速重传和快速恢复算法
如果收到3个重复ACK，可认为该报文段已经丢失，此时无需等待超时定时器溢出，直接重传丢失的包，这就叫快速重传算法。而接下来执行的不是慢启动而是拥塞避免算法，这就叫快速恢复算法。
(1)当收到第3个重复的ACK时，将ssthresh设置为当前拥塞窗口cwnd的一半，重传丢失的报文段，设置cwnd为ssthresh加上3倍的报文段大小。
(2)每次收到另一个重复的ACK时，cwnd增加1个报文段大小并发送1个分组(如果新的cwnd允许发送)。
(3)当下一个确认新数据的ACK到达时，设置cwnd为ssthresh(在第1步中设置的值)。这个ACK应该是在进行重传后的一个往返时间内对步骤1中重传的确认。另外，这个ACK也应该是对丢失的分组和收到的第1个重复的ACK之间的所有中间报文段的确认。这一步采用的是拥塞避免，因为当分组丢失时我们将当前的速率减半。
21.5 重新分组
当TCP超时并重传时，它不一定需要重传同样的报文段。相反，TCP允许进行重新分组而发送一个较大的报文段，这将有助于提高性能（当然，这个较大的报文段不能够超过接收方声明的MSS）。
第22章 TCP的坚持定时器
22.1 坚持定时器
ACK的传输并不可靠。TCP不对ACK报文段进行确认，只确认那些包含有数据的ACK报文段。
TCP通过让接收方指明希望从发送方接收的数据字节数（即窗口大小）来进行流量控制。若当接收窗口大小为0，并且接收方发送的窗口通告确认丢失了，那接收方等待接收数据，而发送方在等待允许它继续发送数据的窗口更新，这样就形成了死锁。为了防止这种死锁，发送方使用一个坚持定时器来周期性地向接收方查询，以便发现窗口是否增大。这些从发送方发出的报文段称为窗口探查。
计算坚持定时器时使用了普通的TCP指针退避，窗口探查报文包含一个字节的数据：首次超时时间是1.5秒，之后的超时时间增加一倍，但总在5～60秒之间。
坚持状态与21章介绍的重传超时之间一个不同的特点就是TCP从不放弃发送窗口探查。这些探查每隔60秒发送一次，这个过程将持续到窗口打开或者应用进程使用的连接被终止。
22.2 糊涂窗口综合症
糊涂窗口综合症：接收方可以通告一个小的窗口（而不是一直等到有大的窗口时才通告），而发送方可以通过这个小窗口发送少量的数据（而不是等待其它的数据以便发送一个大的报文段），即少量的数据通过连接交换，而不是满长度的报文段，TCP的传输效率可想而知。
如何避免“糊涂窗口综合症”：
接收方：接收方不通告小窗口，除非增加一个报文段(MMS)或者接收方缓存空间的一半，否则通告为0。
发送方：可以发送一个满长度的报文段(MMS)；可以发送至少接收方通告窗口一半的报文段；能够发送手头的所有数据并且不希望接收ACK，或者该连接禁止了Nagle算法时，可以发送任意数据。
坚持定时器工作流程:
(1)发送端收到0窗口通告后，就启动坚持定时器，并在定时器溢出的时候向客户端查询窗口是否已经增大。
(2)在定时器未到，就收到非零通告，则关闭该定时器，并发送数据。
(3)若定时器已到，还没有收到非零通告，就发探查报文。
(4)如果探查报文ACK的通告窗口为0，就将坚持定时器的值加倍，TCP的坚持定时器使用1，2，4，8，16……64秒这样的普通指数退避序列来作为每一次的溢出时间，重复1、2、3步，如果通告窗口非零，发送数据，关闭定时器。
第23章 保活定时器
现实中可能存在这么一种空闲TCP连接：没有任何数据流通过。也就是说，如果TCP连接的双方都没有向对方发送数据，则在两个TCP模块之间不交换任何信息，这意味着我们可以启动一个客户与服务器建立连接，然后长时间不使用，而连接依然保持。中间的路由器可以崩溃和重启，电话线可以被挂断再连接，但只要两端的主机没有被重启，则连接依然保持建立。
然而，许多时候一个服务器希望知道客户主机是否崩溃并关机或者崩溃又重新启动，许多实现提供的保活定时器可以提供这种能力。保活并不是TCP规范中的一部分。
保活定时器工作原理：
如果一个给定的连接在2小时内没有任何动作，那么服务器就向客户发送一个探查报文段。客户主机必须处于以下4个状态之一：
(1)客户主机依然正常运行，并从服务器可达。客户的TCP响应正常，而服务器也知道对方的正常工作的，服务器在2小时内将保活定时器复位。
(2)客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的TCP都没有响应，服务器将不能收到对探查的响应，并在75秒后超时，总共发送10个探查，每个间隔75秒。如果服务器没有收到一个响应，它就认为客户主机已经关闭并终止连接。
(3)客户主机崩溃并已经重新启动。这是服务器将收到一个对其保活探查的响应，但这个响应是一个RST复位，使得服务器终止这个连接。
(4)客户主机正常运行，但是从服务器不可达。这与状态2相同，因为TCP不能够区分状态4与2之间的区别，它所能发现的就是没有收到探查的响应。
服务器不用关注客户主机被关闭和重新启动的情况，当系统被操作员关闭时，所有的应用进程也被终止，这会使客户的TCP在连接上发出一个FIN。接收到FIN将使服务器的TCP向服务器进程报告文件结束，使服务器可以检测到这个情况。
