Java程序员必须掌握的网站知识——TCP
本文主要通过整理网络上的资料，整理出的关于TCP方面的简单理论知识。作为Java程序员虽然更多的时候我们都是直接调用现成的API，但是对网络知识有个宏观的概念能方便我们更好的编写代码。当然，文中涉及的理论都是很浅的，也期待后期同大家一同深入的学习和分享。 【兄弟篇】：Java程序员必须掌握的网站知识 —— HTTP
TCP 协议头部格式
- Source Port和Destination Port:分别占用16位，表示源端口号和目的端口号；用于区别主机中的不同进程，而IP地址是用来区分不同的主机的，源端口号和目的端口号配合上IP首部中的源IP地址和目的IP地址就能唯一的确定一个TCP连接；
- Sequence Number：用来标识从TCP发端向TCP收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节在数据流中的序号；主要用来解决网络报乱序的问题；
- Acknowledgment Number：32位确认序列号包含发送确认的一端所期望收到的下一个序号，因此，确认序号应当是上次已成功收到数据字节序号加1。不过，只有当标志位中的ACK标志为1时该确认序列号的字段才有效。主要用来解决不丢包的问题；
- Offset：给出首部中32 bit字的数目，需要这个值是因为任选字段的长度是可变的。这个字段占4bit（最多能表示15个32bit的的字，即4*15=60个字节的首部长度），因此TCP最多有60字节的首部。然而，没有任选字段，正常的长度是20字节；
- TCP Flags：TCP首部中有6个标志比特，它们中的多个可同时被设置为1，主要是用于操控TCP的状态机的，依次为URG，ACK，PSH，RST，SYN，FIN。每个标志位的意思如下：
- URG：此标志表示TCP包的紧急指针域有效，用来保证TCP连接不被中断，并且督促中间层设备要尽快处理这些数据；
- ACK：此标志表示应答域有效，就是说前面所说的TCP应答号将会包含在TCP数据包中；有两个取值：0和1，为1的时候表示应答域有效，反之为0；
- PSH：这个标志位表示Push操作。该标志通知接收方将接收到的数据全部提交给接收进程。这里所说的数据包括与此PUSH包一起传输的数据以及之前就为该进程传输过来的数据。
- RST：这个标志表示连接复位请求。用来复位那些产生错误的连接，也被用来拒绝错误和非法的数据包；
- SYN：表示同步序号，用来建立连接。SYN标志位和ACK标志位搭配使用，当连接请求的时候，SYN=1，ACK=0；连接被响应的时候，SYN=1，ACK=1；这个标志的数据包经常被用来进行端口扫描。扫描者发送一个只有SYN的数据包，如果对方主机响应了一个数据包回来 ，就表明这台主机存在这个端口；但是由于这种扫描方式只是进行TCP三次握手的第一次握手，因此这种扫描的成功表示被扫描的机器不很安全，一台安全的主机将会强制要求一个连接严格的进行TCP的三次握手；
- FIN：用来结束一个TCP回话.但对应端口仍处于开放状态,准备接收后续数据。
- Window：窗口大小，也就是有名的滑动窗口，用来进行流量控制。
TCP 三次握手
三次握手的目的是a）同步连接双方的序列号；b）同步连接双方的确认号；c）交换 TCP窗口大小，等信息。
①【服务端】首先是服务器初始化的过程，从CLOSED（关闭）状态开始通过顺序调用SOCKET、BIND、LISTEN和ACCEPT原语创建Socket套接字，进入LISTEN（监听）状态，等待客户端的TCP传输连接请求。 ②【客户端】客户端最开始也是从CLOSED状态开始调用SOCKET原语创建新的Socket套接字，然后在需要再调用CONNECT原语，向服务器发送一个将SYN字段置1（表示此为同步数据段）的数据段（假设初始序号为i），主动打开端口，进入到SYN SENT（已发送连接请求，等待对方确认）状态。 ③【服务端】服务器在收到来自客户端的SYN数据段后，发回一个SYN字段置1（表示此为同步数据段），ACK字段置1（表示此为确认数据段），ack（确认号）=i+1的应答数据段（假设初始序号为j），被动打开端口，进入到SYN RCVD（已收到一个连接请求，但未进行确认）状态。这里要注意的是确认号是i+1，而不是i，表示服务器希望接收的下一下数据段序号为i+1。 ④【客户端】客户端在收到来自服务器的SYN+ACK数据段后，向服务器发送一个ACK=1（表示此为确认数据段），序号为i+1，ack=j+1的确认数据段，同时进入ESTABLISHED（连接建立）状态，建立单向连接。要注意的是，此时序号为i+1，确认号为j+1，表示客户端希望收到服务器的下一个数据段的序号j+1。 ⑤【服务端】服务器在收到客户端的ACK数据段后，进入ESTABLISHED状态，完成双向连接的建立。
- 双方同时主动连接的TCP连接建立过程
当出现同时发出连接请求时，则两端几乎在同时发送一个SYN字段置1的数据段，并进入SYN_SENT状态。当每一端收到SYN数据段时，状态变为SYN_RCVD，同时它们都再发送SYN字段置1，ACK字段置1的数据段，对收到的SYN数据段进行确认。当双方都收到对方的SYN+ACK数据段后，便都进入ESTABLISHED状态。图10-39显示了这种同时发起连接的连接过程，但最终建立的是一个TCP连接，而不是两个，这点要特别注意。 从图中可以看出，一个双方同时打开的传输连接需要交换4数据段，比正常的传输连接建立所进行的三次握手多交换一个数据段。此外要注意的是，此时我们没有将任何一端称为客户或服务器，因为每一端既是客户又是服务器。
- Q & A Q：三次握手建立连接时，发送方再次发送确认的必要性 A：防止已失效的请求报文段突然又传送到了服务端而造成连接的误判。假如客户端发出连接请求A，由于网络原因，服务端并没有收到A，于是客户端又发送了连接请求B，并建立了连接，完成通信，断开连接。这时候，服务端突然又收到了A，于是看作是一次新的连接请求，进行第二次握手，由于不存在第三次握手，所以这时已经建立了TCP连接。但实际上客户端并没有发起连接，所以不会传递数据，那么这条连接就会变成一条死连接。
TCP 的四次挥手
TCP协议有一个优雅的关闭（graceful close）机制，以保证应用程序在关闭连接时不必担心正在传输的数据会丢失。这个机制还设计为允许两个方向的数据传输相互独立地终止。 关闭机制的工作流程是：应用程序通过调用连接套接字的close()方法或shutdownOutput()方法表明数据已经发送完毕。此刻，底层的TCP实现首先将留存在SendQ队列中的数据传输出去（还要依赖于另一端RecvQ队列的剩余空间），然后向另一端发送一个关闭TCP连接的握手消息。该关闭握手消息可以看作是流终止标志：它告诉接收端TCP不会再有新的数据传入RecvQ队列了。（注意，关闭握手消息本身并没有传递给接收端应用程序，而是通过read()方法返回-1来指示其在字节流中的位置。）正在关闭的TCP将等待其关闭握手消息的确认信息，该确认信息表明在连接上传输的所有数据已经安全地传输到了RecvQ中。只要收到了确认消息，该连接就变成"半关闭（Half closed）"状态。直到连接的另一个方向上收到了对称的握手消息后，连接才完全关闭--也就是说，连接的两端都表明它们再没有数据要发送了。
①【主动关闭端】TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送。然后，进入FIN_WAIT_1状态。 ②【被动关闭端】服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。然后，进入CLOSE_WAIT状态。 ③【主动关闭端】客户端收到FIN的确认报文段，进入FIN_WAIT_2状态。 ④【被动关闭端】服务器关闭客户端的连接，发送一个FIN给客户端，进入LAST_ACK状态。 ⑤【主动关闭端】客户端收到FIN报文端，发送FIN的ACK，同时进入TIME_WAIT状态，启动TIME_WAIT定时器，超时时间设为2MSL。 ⑥【被动关闭端】服务器端收到FIN的ACK，进入CLOSED状态。 ⑦【主动关闭端】客户端在2MSL时间内没收到对端的任何响应，TIME_WAIT超时，进入CLOSED状态。
- 两端同时关闭TCP连接
当两端对应的网络应用层进程同时调用CLOSE原语，发送FIN数据段执行关闭命令时，两端均从ESTABLISHED状态转变为FIN WAIT 1状态。任意一方收到对端发来的FIN数据段后，其状态均由FIN WAIT 1转变到CLOSING状态，并发送最后的ACK数据段。当收到最后的ACK数据段后，状态转变化TIME_WAIT，在等待2MSL后进入到CLOSED状态，最终释放整个TCP传输连接。
- Q & A Q: 为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？ A: 这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。
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: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到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可用状态了。
TCP 的 TIME_WAIT 状态
在TCP的状态图中，从TIME_WAIT状态到CLOSED状态，有一个超时设置，这个超时设置是 2*MSL（RFC793定义了MSL为2分钟，Linux设置成了30s。这意味着TIME_WAIT的典型持续时间为1-4分钟。）
IP头部有一个TTL，最大值255。尽管TTL的单位不是秒(根本和时间无关)，我们仍需假设，TTL为255的TCP报文在Internet上生存时间不能超过MSL。
- 为什么要这有TIME_WAIT？为什么不直接给转成CLOSED状态呢？
主要有两个原因： ① 为尽最大可能的实现TCP这种全双工（full-duplex）连接的可靠释放 TIME_WAIT确保有足够的时间让对端收到了ACK，如果被动关闭的那方没有收到Ack，就会触发被动端重发Fin，一来一去正好2个MSL。 假设最后一个ACK丢失了，被动关闭一方会重发它的FIN。主动关闭一方必须维持一个有效状态信息（TIMEWAIT状态下维持），以便能够重发ACK。如果主动关闭的socket不维持这种状态而进入CLOSED状态，那么主动关闭的socket在处于CLOSED状态时，接收到FIN后将会响应一个RST。被动关闭一方接收到RST后会认为出错了。
② 为使旧的数据包在网络因过期而消失，以防止lost duplicate对后续新建正常链接的传输造成破坏。 有足够的时间让这个连接不会跟后面的连接混在一起，即，允许老的重复报文段在网络中消逝（你要知道，有些自做主张的路由器会缓存IP数据包，如果连接被重用了，那么这些延迟收到的包就有可能会跟新连接混在一起）。 TCP报文段可能由于路由器异常而“迷途”，在迷途期间，TCP发送端可能因确认超时而重发这个分节，迷途的分节在路由器修复后也会被送到最终目的地，这个 原来的迷途分节就称为lost duplicate。在关闭一个TCP连接后，马上又重新建立起一个相同的IP地址和端口之间的TCP连接，后一个连接被称为前一个连接的化身 （incarnation)，那么有可能出现这种情况，前一个连接的迷途重复分组在前一个连接终止后出现，从而被误解成从属于新的化身。为了避免这个情况，TCP不允许处于TIME_WAIT状态的连接启动一个新的化身，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个TCP连接的时候，来自连接先前化身的重复报文段已经在网络中消逝。
- 关于TIME_WAIT数量太多
在高并发短连接的TCP服务器上，当服务器处理完请求后立刻按照主动正常关闭连接。这个场景下，会出现大量socket处于TIMEWAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。 因此，关于高并发的短连接，我们需要注意： a）高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围（当客户端为同一ip的情况下），并不是很多，刨除系统和其他服务要用的，剩下的就更少了。 b）在这个场景中，短连接表示“业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间”的连接。单用这个业务计算服务器的利用率会发现，服务器干正经事的时间和端口（资源）被挂着无法被使用的时间的比例是 1：几百，服务器资源严重浪费。
综合这两个方面，持续的到达一定量的高并发短连接，会使服务器因端口资源不足而拒绝为一部分客户服务。同时，这些端口都是服务器临时分配，无法用SO_REUSEADDR选项解决这个问题:(
- 解决方案
① 利用SO_LINGER选项的强制关闭方式，发RST而不是FIN，来越过TIMEWAIT状态，直接进入CLOSED状态。 设置 l_onoff为非0，l_linger为0，则套接口关闭时TCP夭折连接，TCP将丢弃保留在套接口发送缓冲区中的任何数据并发送一个RST给对方，而不是通常的四分组终止序列，这避免了TIME_WAIT状态。
② 设置tcp_tw_reuse、tcp_tw_recycle参数 只要搜一下，你就会发现，十有八九的处理方式都是教你设置两个参数，一个叫tcp_tw_reuse，另一个叫tcp_tw_recycle的参数，这两个参数默认值都是被关闭的，后者recyle比前者resue更为激进，resue要温柔一些。另外，如果使用tcp_tw_reuse，必需设置tcp_timestamps=1，否则无效。这里，你一定要注意，打开这两个参数会有比较大的坑——可能会让TCP连接出一些诡异的问题（因为如上述一样，如果不等待超时重用连接的话，新的连接可能会建不上。正如官方文档上说的一样“It should not be changed without advice/request of technical experts”）。
③ 一般情况下出现TIME_WAIT状态的都是客户端，在业务逻辑中尽量让客户端主动关闭连接，这样也就将TIME_WAIT变相的转载了。但是在有些业务中必须让服务器主动关闭连接。 对于基于TCP的HTTP协议，关闭TCP连接的是Server端，这样，Server端会进入TIME_WAIT状态，可想而知，对于访问量大的Web Server，会存在大量的TIME_WAIT状态。 HTTP协议1.1版规定default行为是Keep-Alive，也就是会重用TCP连接传输多个request/response，一个主要原因就是发现了这个问题。
TCP 流量控制 和 拥塞控制
流量控制是通过接收方来控制流量的一种方式；而拥塞控制则是通过发送方来控制流量的一种方式。
- 拥塞控制
拥塞控制的任务是确保子网能够承载所到达的流量。这是一个全局性问题，涉及到各方面的行为，包括所有的主机、所有的路由器、路由器内部的存储转发处理过程，以及所有可能会削弱子网承载容量的其它因素。 网络拥塞现象是指到达通信子网中某一部分的分组数量过多,使得该部分网络来不及处理,以致引起这部分乃至整个网络性能下降的现象,严重时甚至会导致网络通信业务陷入停顿,即出现死锁现象。拥塞控制是处理网络拥塞现象的一种机制。
TCP的慢启动（拥塞窗口）： TCP在局域网环境中的效率是很高的，但是到了广域网的环境中情况就不同了，在发送方和接收方之间可能存在多个Router以及一些速率比较慢的链路，而且一些中继路由器必须缓存分组，还可能分片，所以在广域网的环境中，TCP的效率可能出现问题。 为了解决这个问题，现在的TCP栈都支持“慢启动”算法，即拥塞窗口控制算法。其实，拥塞窗口是发送方使用的一种流量控制算法。 慢启动为TCP的发送方增加了一个拥塞窗口，当连接建立时，拥塞窗口被初始化为一个报文段大小，每收到一个ACK，拥塞窗口就会增加一个报文段，发送方取拥塞窗口与滑动窗口的最小值作为发送的上限。
- 流量控制
流量控制只与特定的发送方和特定的接收方之间的点到点流量有关。它的任务是，确保一个快速的发送方不会持续地以超过接收方吸收能力的速率传输数据，以免数据丢失。
滑动窗口： TCP使用滑动窗口协议来进行流量控制。特别需要注意的是，滑动窗口是一个抽象的概念，它是针对每一个TCP连接的，而且是有方向的，一个TCP连接应该有两个滑动窗口，每个数据传输方向上有一个，而不是针对连接的每一端的。 当左边沿和右边沿重合的时候表明窗口大小是0，此时发送方不应该在发送数据了，因为接收方的接收缓冲区已满，用户进程还没以接收。当用户进程接收完成后，接收方应该发送一个ACK，表明此时的接收窗口已经恢复，此ACK的序号同前一个win为0的ACK相同。 TCP窗口大小的调整：TCP窗口的大小通常由接收端来确认，也就是在TCP建立连接的第二个SYN+ACK报文的Win字段来确认。
- 小结
sock API允许进程设置发送和接收缓存的大小。接收缓存的大小是该连接上所能够通告的最大窗口大小。 发送方一开始便向网络发送多个报文段，直至的窗口达到接收方通告大小为止。当发送方和接收方处于同一个局域网时，这种方式是可以的。但是如果在发送方和接收方之间存在多个路由器和速率较慢的链路时，就有可能出现一些问题。一些中间路由器必须缓存分组，并有可能耗尽存储器的空间。TCP需要支持一种被称为慢启动的算法。该算法通过观察到新分组进入网络的速率应该与另一端返回确认的速率相同而进行工作。 慢启动为发送方的TCP增加了另一个窗口：拥塞窗口，cwnd。 当与另一个网络的主机建立TCP连接时，拥塞窗口被初始化为1个报文段，即另一端通过的报文段大小。每收到一个ACK，拥塞窗口就增加一个报文段,cwnd以字节为单位，但是慢启动以报文段大小为单位进行增加。发送方取拥塞窗口与滑动窗口中的最小值作为发送上限。拥塞窗口是发送方使用的流量控制，而滑动窗口则是接收方使用的流量控制。 发送方开始时发送一个报文段，然后等待ACK。当接收该ACK时，拥塞窗口从1增加为2，即可以发送2个报文段。当收到这2个报文段的ACK时，拥塞窗口就增加为4。这是一种指数增加的关系。
TCP 的 接收缓冲区 和 发送缓冲区
先明确一个概念：每个TCP socket在内核中都有一个发送缓冲区和一个接收缓冲区，TCP的全双工的工作模式以及TCP的滑动窗口便是依赖于这两个独立的buffer以及此buffer的填充状态。
接收缓冲区： 接收缓冲区把数据缓存入内核，应用进程一直没有调用read进行读取的话，此数据会一直缓存在相应 socket的接收缓冲区内。再啰嗦一点，不管进程是否读取socket，对端发来的数据都会经由内核接收并且缓存到socket的内核接收缓冲区之中。 read所做的工作，就是把内核缓冲区中的数据拷贝到应用层用户的buffer里面，仅此而已。 接收缓冲区被TCP和UDP用来缓存网络上来的数据，一直保存到应用进程读走为止。对于TCP，如果应用进程一直没有读取，buffer满了之后，发生的动作是：通知对端TCP协议中的窗口关闭。这个便是滑动窗口的实现。保证TCP套接口接收缓冲区不会溢出，从而保证了TCP是可靠传输。因为对方不允许发出超过所通告窗口大小的数据。 这就是TCP的流量控制，如果对方无视窗口大小而发出了超过窗口大小的数据，则接收方TCP将丢弃它。
发送缓冲区： 进程调用send发送的数据的时候，最简单情况(也是一般情况)，将数据拷贝进入socket的内核发送缓冲区之中，然后send便会在上层返回。换句话说，send返回之时，数据不一定会发送到对端去(和 write写文件有点类似)，send仅仅是把应用层buffer的数据拷贝进socket的内核发送buffer中，但不代表将数据发送给对端。发送给对端成功的标志是接受到对端的ACK回应，这个时候发送端才可以将发送缓冲区的数据丢弃。不丢弃的原因是时刻准备重发丢失/出错的数据！
UDP： 每个UDP socket都有一个接收缓冲区，没有发送缓冲区，从概念上来说就是只要有数据就发，不管对方是否可以正确接收，所以不缓冲，不需要发送缓冲区。 关于UDP，当套接口接收缓冲区满时，新来的数据报无法进入接收缓冲区，此数据报就被丢弃。UDP是没有流量控制的;快的发送者可以很容易地就淹没慢的接收者，导致接收方的UDP丢弃数据报。
TCP 的 ACK 包
什么时候发送ACK确认数据包： ① 收到1个包，启动200ms定时器，等到200ms的定时器到点了（第二个包没来），于是对这个包的确认ack被发送。这叫做“延迟发送”； ② 收到1个包，启动200ms定时器，200ms定时器还没到，第二个数据包又来了（两个数据包一个ack）； ③ 收到1个包，启动200ms定时器，还没超时，正好要给对方发点内容。于是对这个包的确认ack就跟着捎过去。这叫做“捎带发送”；
④ 每当TCP接收到一个超出期望序号的失序数据时，它总是发送一个确认序号为其期望序号的ACK； ⑤ 窗口更新或者也叫做打开窗口，通知发送端可以继续发送； ⑥ 正常情况下对对方保活探针的响应
TCP 的 RST 包
有以下情况会发送RST包 ① connect一个不存在的端口； ② 向一个已经关掉的连接send数据； ③ 向一个已经崩溃的对端发送数据（连接之前已经被建立）； ④ close(sockfd)时，直接丢弃发送缓冲区中为发送的数据，并给对方发一个RST。这个是由SO_LINGER选项来控制的； ⑤ a重启，收到b的保活探针，a发rst，通知b。 TCP socket在任何状态下，只要收到RST包，即可进入CLOSED初始状态。 值得注意的是RST报文段不会导致另一端产生任何响应，另一端根本不进行确认。收到RST的一方将终止该连接。程序行为如下：
- 阻塞模型下，内核无法主动通知应用层出错，只有应用层主动调用read()或者write()这样的IO系统调用时，内核才会利用出错来通知应用层对端RST。
- 非阻塞模型下，select或者epoll会返回sockfd可读,应用层对其进行读取时，read()会报错RST。
TCP 关键术语
- MTU ———— 最大传输单元
首先要看TCP/IP协议，涉及到四层：链路层，网络层，传输层，应用层。 其中以太网（Ethernet）的数据帧在链路层 IP包在网络层 TCP或UDP包在传输层 TCP或UDP中的数据（Data)在应用层 它们的关系是 数据帧｛IP包｛TCP或UDP包｛Data｝｝｝
在应用程序中我们用到的Data的长度最大是多少，直接取决于底层的限制。 我们从下到上分析一下： 1.在链路层，由以太网的物理特性决定了数据帧的长度为（46＋18）－（1500＋18），其中的18是数据帧的头和尾，也就是说数据帧的内容最大为1500（不包括帧头和帧尾），即MTU（Maximum Transmission Unit）为1500； 2.在网络层，因为IP包的首部要占用20字节，所以这的MTU为1500－20＝1480； 3.在传输层，对于UDP包的首部要占用8字节，所以这的MTU为1480－8＝1472； 所以，在应用层，你的Data最大长度为1472。 （当我们的UDP包中的数据多于MTU(1472)时，发送方的IP层需要分片fragmentation进行传输，而在接收方IP层则需要进行数据报重组，由于UDP是不可靠的传输协议，如果分片丢失导致重组失败，将导致UDP数据包被丢弃）。 从上面的分析来看，在普通的局域网环境下，UDP的数据最大为1472字节最好（避免分片重组）。 但在网络编程中，Internet中的路由器可能有设置成不同的值（小于默认值），Internet上的标准MTU值为576，所以Internet的UDP编程时数据长度最好在576－20－8＝548字节以内。
路径MTU： 当在同一个网络上的两台主机互相进行通信时，该网络的MTU是非常重要的。但是如果两台主机之间的通信要通过多个网络，那么每个网络的链路层就可能有不同的MTU。重要的不是两台主机所在网络的MTU的值，重要的是两台通信主机路径中的最小MTU。它被称作路径MTU。 两台主机之间的路径MTU不一定是个常数。它取决于当时所选择的路由。而选路不一定是对称的（从A到B的路由可能与从B到A的路由不同），因此路径MTU在两个方向上不一定是一致的。
- MSS ———— 最大报文长度
在建立连接的时候，通信的双方要互相确认对方的最大报文长度(MSS)，以便通信。一般这个MSS长度是MTU减去固定IP首部和TCP首部长度。对于一个以太网，一般可以达到1460字节。当然如果对于非本地的IP，这个MSS可能就只有536字节，而且，如果中间的传输网络的MSS更佳的小的话，这个值还会变得更小。 当一个连接建立时【三次握手】，连接的双方都要通告各自的MSS。当建立一个连 接时，每一方都有用于通告它期望接收的MSS选项（MSS选项只能出现在SYN报文段中）。如果一方不接收来自另一方的MSS值，则MSS就定为默认值536字节（这个默认值允许20字节的IP首部和20字节的TCP首部以适合576字节IP数据报)。 【MSS=外出接口上的MTU-IP首部-TCP首部】 故采用TCP协议进行数据传输，是不会造成IP分片的。若数据过大，只会在传输层进行数据分段，到了IP层就不用分片。 总结：UDP不会分段，就由IP来分。TCP会分段，当然就不用IP来分了！
IP分片产生的原因是链路层的MTU；TCP分段产生原因是MSS.
但在实际场景中，TCP网络传输的数据包大小不是1460字节，而是1448字节。这是因为，实际场景下，TCP包头中会带有12字节的选项----时间戳。这样，单个TCP包实际传输的最大量就缩减为1448字节。1448=1500-20（IP头）-32（20字节TCP头和12字节TCP选项时间戳）。 即，1460的MSS；1448的负载。
- MSL（Maximum Segment Lifetime）———— 报文最大生存时间
每个TCP报文在网络内的最长时间，就称为MSL（Maximum Segment Lifetime），它的作用和IP数据包的TTL类似。RFC793指出，MSL的值是2分钟，但是在实际的实现中，常用的值有以下三种：30秒，1分钟，2分钟。 每个具体TCP实现必须选择一个报文段最大生存时间MSL(Maximum Segment Lifetime)。它是任何报文段被丢弃前在网络内的最长时间。我们知道这个时间是有限的，因为TCP报文段以IP数据报在网络内传输，而IP数据报则有限制其生存时间的TTL字段。
- ** RTT（Round-Trip Time） ———— 往返时间**
是指一个报文段从发出去到收到此报文段的ACK所经历的时间。通常一个报文段的RTT与传播时延和发送时延两个因素相关。
TCP 选项
- SO_REUSEADDR
这个套接字选项通知内核，如果端口忙，但TCP状态处于TIME_WAIT，可以重用端口。如果端口忙，TCP状态处于其他状态，重用端口时依旧指明“地址已经在使用中”。如果你的服务程序停止后向立刻重启，而新套接字依旧使用同一个端口，此时SO_REUSEADDR选项非常有用。但是如果前一个连接处于TIME_WAIT状态，而允许另一个拥有相同五元组连接出现，可能处理TCP报文时，两个连接互相干扰。所以使用SO_REUSEADDR选项就需要考虑这种情况。
一个套接字由五个部分组成：协议，本地地址，本地端口，远程地址和远程端口。SO_REUSEADDR仅仅表示可以重用本地地址，本地端口。
- SO_LINGER
此选项指定函数close对面向连接的协议如何操作（如TCP）。内核缺省close操作是立即返回，如果有数据残留在套接口缓冲区中则系统将试着将这些数据发送给对方。
有下列三种情况： ① 设置 l_onoff为0，则该选项关闭，l_linger的值被忽略，等于内核缺省情况，close调用会立即返回给调用者，如果可能将会传输任何未发送的数据； ② 设置 l_onoff为非0，l_linger为0，则套接口关闭时TCP夭折连接，TCP将丢弃保留在套接口发送缓冲区中的任何数据并发送一个RST给对方，而不是通常的四分组终止序列，这避免了TIME_WAIT状态； ③ 设置 l_onoff 为非0，l_linger为非0，当套接口关闭时内核将拖延一段时间（由l_linger决定）。如果套接口缓冲区中仍残留数据，进程将处于睡眠状态，直 到（a）所有数据发送完且被对方确认，之后进行正常的终止序列（描述字访问计数为0）或（b）延迟时间到。此种情况下，应用程序检查close的返回值是非常重要的，如果在数据发送完并被确认前时间到，close将返回EWOULDBLOCK错误且套接口发送缓冲区中的任何数据都丢失。close的成功返回仅告诉我们发送的数据（和FIN）已由对方TCP确认，它并不能告诉我们对方应用进程是否已读了数据。如果套接口设为非阻塞的，它将不等待close完成。
个人认为，①和③的区别在于，①仅会尽最大努力去保证发送缓冲区中的数据会成功发送给对端，即使不成功，close操作也不会失败，也就说close操作会正确返回；而③的话，如果发送缓冲区的数据没有在我们设定的时间内成功发送出去（即，收到ACK包才算是成功发送），则close操作将返回EWOULDBLOCK错误。
TCP重传机制
TCP要保证所有的数据包都可以到达，所以，必需要有重传机制。 注意，接收端给发送端的Ack确认只会确认最后一个连续的包，比如，发送端发了1,2,3,4,5一共五份数据，接收端收到了1，2，于是回ack 3，然后收到了4（注意此时3没收到），此时的TCP会怎么办？我们要知道，因为正如前面所说的，SeqNum和Ack是以字节数为单位，所以ack的时候，不能跳着确认，只能确认最大的连续收到的包，不然，发送端就以为之前的都收到了。
- 超时重传机制
一种是不回ack，死等3，当发送方发现收不到3的ack超时后，会重传3。一旦接收方收到3后，会ack 回 4——意味着3和4都收到了。 但是，这种方式会有比较严重的问题，那就是因为要死等3，所以会导致4和5即便已经收到了，而发送方也完全不知道发生了什么事，因为没有收到Ack，所以，发送方可能会悲观地认为也丢了，所以有可能也会导致4和5的重传。 对此有两种选择：1 ① 一种是仅重传timeout的包。也就是第3份数据。 ② 另一种是重传timeout后所有的数据，也就是第3，4，5这三份数据。 这两种方式有好也有不好。第一种会节省带宽，但是慢，第二种会快一点，但是会浪费带宽，也可能会有无用功。但总体来说都不好。因为都在等timeout，timeout可能会很长（在下篇会说TCP是怎么动态地计算出timeout的）
- 快速重传机制 于是，TCP引入了一种叫Fast Retransmit的算法，不以时间驱动，而以数据驱动重传。也就是说，如果，包没有连续到达，就ack最后那个可能被丢了的包，如果发送方连续收到3次相同的ack，就重传。Fast Retransmit的好处是不用等timeout了再重传。 比如：如果发送方发出了1，2，3，4，5份数据，第一份先到送了，于是就ack回2，结果2因为某些原因没收到，3到达了，于是还是ack回2，后面的4和5都到了，但是还是ack回2，因为2还是没有收到，于是发送端收到了三个ack=2的确认，知道了2还没有到，于是就马上重转2。然后，接收端收到了2，此时因为3，4，5都收到了，于是ack回6。示意图如下：
Fast Retransmit只解决了一个问题，就是timeout的问题，它依然面临一个艰难的选择，就是重转之前的一个还是重装所有的问题。对于上面的示例来说，是重传#2呢还是重传#2，#3，#4，#5呢？因为发送端并不清楚这连续的3个ack(2)是谁传回来的？也许发送端发了20份数据，是#6，#10，#20传来的呢。这样，发送端很有可能要重传从2到20的这堆数据（这就是某些TCP的实际的实现）。可见，这是一把双刃剑。
TCP 封包、粘包、半包
- 粘包、拆包发生原因
① 要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包。 ② 待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。 ③ 要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。 ④ 接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。 等等。
- 粘包、拆包解决办法
常用的方法有如下几个： ① 发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。 ② 发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。 ③ 可以在数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开。 等等。
一台服务器所能承受的最大TCP连接数
诶，其实无论是客户端还是服务器端。这个问题都没这么复杂。 我们通过五元组来表示一个连接：【服务器IP + 服务器端口 + TCP + 客户端IP + 客户端端口】只要保证这个五元组是唯一的，就可以唯一识别一个session。
ip使用32位长（4字节）表示；port使用16位长（2字节）表示。意味着有2^16= 65536个端口号可用，但0-1023通常为系统保留端口，所以最多有64512个端口做为端口池资源。
那么，做个简单的假设。 关于服务端：只有一个监听端口。理论上可以接受多少个TCP连接了？ 这里，local ip 和 local port 都是固定的了。所以，理论上服务器的一个监听端口能接收【2 ^ 32 * 64512】个连接。如果忽略系统保留端口的话，则是【2^32 * 2^16 = 2^48】
关于客户端：假设，客户端只连接某个固定ip服务器的某个端口。那么，理论上该客户端可以对这个服务器发起多少个TCP请求了？ 这里，local ip 、remote ip 都是固定的了。注意，你可以想想。当两端ip都是固定的情况下。实际上port就只能对应了。也就说，只会有2^16个连接。
但是了，在实际的场景中，并发连接数受限于系统能同时打开的文件数目的最大值。因为这个数值往往远小于我们讨论的理论值。
TCP保证可靠性的简单工作原理
- 应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的数据报长度将保持不变。由TCP传递给IP的信息单位称为报文段或段（ segment）。
- 当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
- 当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒。
- TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错， TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。
- 既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要， TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。
- TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。
补充和扩展
- 关于长连接和短连接
通俗点讲，短连接就是一次TCP请求得到结果后,连接马上结束.而长连接并不马上断开,而一直保持着,直到长连接TIMEOUT(具体程序都有相关参数说明).长连接可以避免不断的进行TCP三次握手和四次挥手. 长连接(keepalive)是需要靠双方不断的发送探测包来维持的,keepalive期间服务端和客户端的TCP连接状态是ESTABLISHED。
- IP 分片（fragmentation）
当一个IP数据报从某个接口送出时，如果它的大小超过相应链路的MTU，IPv4和IPv6都将执行分片。这些片段在到达终点之前通常不会被重组（reassembling）。
IPv4主机对其产生的数据报执行分片，IPv4路由器则对其转发的数据报进行分片（如，数据报大小大于了该IPv4路由器的MTU值，那么该IPv4路由器就会对这个数据报进行分片）。然后IPv6只有主机对其产生的数据报执行分片，IPv6路由器不对其转发的数据报执行分片。
IPv4首部的“不分片”（do not fragment）位（即DF位）若被设置，那么不管是发送这些数据报的主机还是转发他们的路由器，都不允许对它们分片。当路由器接收到一个超过其外出链路MTU大小且设置了DF位的IPv4数据报时，它将产生一个ICMPv4“destination unreachable,fragmentation needed but DF bit set”（目的不可到达，需分片但DF位已设置）的出错消息。（在进行TCP协议传输时，该DF位会被置位为1） 既然IPv6路由器不执行分片，每个IPv6数据报于是隐含一个DF位。当IPv6路由器接收到一个超过其外出链路MTU大小的IPv6数据报时，它将产生一个ICMPv6 “packet too big”的出错消息。IPv4的DF位和隐含DF位可用于路径MTU发现。
- TCP 参数
TCP_CORK：尽量向发送缓冲区中攒数据，攒到多了再发送，这样网络的有效负载会升高。简单粗暴地解释一下这个有效负载的问题。假如每个包中只有一个字节的数据，为了发送这一个字节的数据，再给这一个字节外面包装一层厚厚的TCP包头，那网络上跑的几乎全是包头了，有效的数据只占其中很小的部分，很多访问量大的服务器，带宽可以很轻松的被这么耗尽。那么，为了让有效负载升高，我们可以通过这个选项指示TCP层，在发送的时候尽量多攒一些数据，把他们填充到一个TCP包中再发送出去。这个和提升发送效率是相互矛盾的，空间和时间总是一堆冤家!! TCP_NODELAY：尽量不要等待，只要发送缓冲区中有数据，并且发送窗口是打开的，就尽量把数据发送到网络上去。
- 举例明白发送/接收缓冲区、滑动窗口协议之间的关系
一个例子明白发送缓冲区、接受缓冲区、滑动窗口协议之间的关系。 在上面的几篇文章中简单介绍了上述几个概念在TCP网络编程中的关系，也对应了几个基本socket系统调用的几个行为，这里再列举一个例子，由于对于每一个TCP的SOCKET来说，都有一个发送缓冲区和接受缓冲区与之对应，所以这里只做单方向交流，不做互动，在recv端不send,在send端不recv。细细揣摩其中的含义。 一、recv端 在监听套接字上准备accept，在accept结束以后不做什么操作，直接sleep很久，也就是在recv端并不做接受数据的操作，在sleep结束之后再recv数据。 二、send端 通过查看本系统内核默认的支持的最大发送缓冲区大小，cat/proc/sys/net/ipv4/tcp_wmem，最后一个参数为发送缓冲区的最大大小。接受缓冲区最大的配置文件在tcp_rmen中。 将套接字设置为阻塞，一次发送的buffer大于最大发送缓冲区所能容纳的数据量，一次send结束，在发送返回后接着答应发送的数据长度
测试结果： 阶段一： 接受端表现：在刚开始发送数据时，接收端处于慢启动状态，滑动窗口大小越来愈大，但是由于接收端不处理接受缓冲区内的数据，其滑动窗口越来越小（因为接受端回应发送端中的win大小表示接受端还能够接受多少数据，发送端下次发送的数据大小不能超过回应中win的大小），最后发送端回应给接受端的ACK中显示的win大小为0，表示接收端不能够再接受数据。 发送端表现：发送端一直不能返回，如果接受端一直回应win为0的情况下，发送端的send就会一直不能返回，这种僵局一直持续到接收端的sleep结束。 原因分析：首先需要明白几个事实，阻塞式I/O会一直等待，直达这个操作完成；发送端接受到接收端的回应后才能将发送缓冲区中的数据进行清空。 在接收端不recv，那么接收端的接受缓冲区内会一直有数据，接受缓冲区满，导致滑动窗口为0，导致发送端不能发送数据。但是send操作为何不能返回呢？send操作只是将应用缓冲区的数据拷贝到发送缓冲区，但是发送缓冲区的数据并没有完全得到接收端的ACK回应，所以暂时不能将发送缓冲区中的数据丢弃，导致发送缓冲区的被填满，这样应用层中的数据也就不能拷贝到内核发送缓冲区内，也就会一直阻塞在这里，直到可以继续讲应用层的数据拷贝到发送缓冲区中，何时触发这个操作呢？等到发送端回应win大于0时才有这样的操作。
阶段二： 接受端：在sleep结束以后，开始调用recv系统调用。这个时候接受端的滑动窗口又开始大于零。那么这样就唤醒了发送端继续发送数据。 发送端：发送端接受到接收端win大于0的回应，这个时候发送端又可以将应用层buffer中的数据拷贝到内核的发送缓冲区中。 原因分析：由于接受端调用recv将内核接受缓冲区的数据拷贝到应用层中，这样滑动窗口又大于0了所以激发了发送端继续发送数据，由于发送端可以发送数据了，内核协议栈便将发送缓冲区中的数据发送给接受端，这样发送缓冲区又有空间了，那么send操作就可以将应用层的数据拷贝到发送缓冲区了！这样的操作一直保持到send操作返回，这样代表着将应用层的数据全部拷贝到发送缓冲区内，但不代表将数据发送给对端。发送给对端成功的标志是接受到对端的ACK回应，这个时候发送端才可以将发送缓冲区的数据丢弃。不丢弃的原因是时刻准备重发丢失/出错的数据！ Ps: TCP通信为了保证可靠性，每次发送的数据都需要得到对方的ACK才确认对方收到了(仅保证对方TCP接收缓冲收到数据了，但不保证对方应用程序取到数据了)，这时如果每次发送一次就要停下来等着对方的ACK消息，显然是一种极大的资源浪费和低下的效率，这时就有了滑动窗口的出现。发送方的滑动窗口维持着当前发送的帧序号，已发出去帧的计时器，接收方当前的窗口大小(由接收方ACK通知，大体等于接收缓冲大小-未处理的消息包)，接收方滑动窗口保存的有已接收的帧信息、期待的下一帧的帧号等，至于滑动窗口的具体工作原理这里就不说了。
- 关于“拥塞控制”
造成拥塞的原因： ① 多条流入线路有分组到达，并需要同一输出线路，此时，如果路由器没有足够的内存来存放所有这些分组，那么有的分组就会丢失。 ② 路由器的慢带处理器的缘故，以至于难以完成必要的处理工作，如缓冲区排队、更新路由表等。 防止拥塞的方法： ① 在传输层可采用：重传策略、乱序缓存策略、确认策略、流控制策略和确定超时策略。 ② 在网络层可采用：子网内部的虚电路与数据报策略、分组排队和服务策略、分组丢弃策略、路由算法和分组生存管理。 ③ 在数据链路层可采用：重传策略、乱序缓存策略、确认策略和流控制策略。
- TCP层的分段和IP层的分片之间的关系 & MTU和MSS之间的关系【实战】
对于TCP来说，它是尽量避免分片的。假设我们这里要发送给TCP层的数据大小为2748个字节，这个大小是明显大于链路层的发送数据的大小的，在这个情况下
我们来看，对于来自TCP层的数据，IP会不会进行分片。
从第一张图看来，应用层的2748个字节在TCP层就进行了分段，分层了两个TCP段，一个1460字节，一个1288字节。那么到IP层的时候，自然就不会在进行分片了。
从第二张图片看出，在这两个TCP分段中，在序号3处，IP的头部字段（Don ' t Fragment） 被设置了，用于告诉IP层不要对该数据进行分片。
而对于MSS大小的协商，我们可以从下面这张图片看到，下面的图片是TCP CLIENT发出的第一个SYN TCP分段：
对于UDP来说，假设我们要发送的一个UDP数据包大小为1600个字节，那么在实际上通过UDP/IP分发出去的时候，会不会进行分片呢? 看如下的图片：
从上面的图片可以看出，我们发送的数据包的大小为1600字节（序号1处），在UDP层，长度为1608字节（序号2处），这里的8个字节是UDP的头部字段的长度， 到了IP层（序号3处），我们可以清楚的看到IP对UDP数据包进行了分片，一个大小为1480字节，一个为128字节。
优质内容筛选与推荐>>1、CLucene 'core' package requires no external dependencies 'contrib' package uses a limited number of dependencies
2、BZOJ3091: 城市旅行(LCT，数学期望)
3、smtp验证发邮件,今天好郁闷,终于解决了
4、Database2Sharp重要更新之数据库文档的生成(国庆专辑，祝福我们的祖国）
5、装饰器的补充以及迭代器