TCP/IP这本书讲TCP链接是如何创建和终止的？

把书读薄(TCP/IP详解 卷一 第十八章)

TCP的三次握手是过程是怎样的？

1. 请求端(客户端)发起第一个SYN，执行主动打开，表示想要链接服务端，同时指明初始序号(ISN,好比这里的141553152)
2. 服务端作出回应，指明本身的初始序号，执行被动打开，同时将确认序号设置成对客户端的初始序号加1，表示确认了客户端的SYN
3. 客户端将确认序号设置成服务端的初始序号加1，表示确认了服务端的SYN

ISN：初始序号，能够看作是一个32比特的计数器，每4ms加1，详见RFC 793

TCP的四次挥手过程是怎样的？

1. 请求端(客户端)想断开链接，因而发出一个FIN包
2. 服务端接收到请求，在确认序号上对客户端的序号加1表示已确认
3. 服务端关闭本身的链接，发出一个FIN包
4. 客户端接收到请求，在确认序号上对服务端序号加1表示已经确认

TCP链接是全双工的，每一个方向都必须单独关闭

创建链接时若是超时了会发生什么事情？

出现场景

服务器在客户端创建链接时恰好断电。能够看出客户端进行了重试，可是重试之间的时间间隔第一次是5.81秒，而第二次间隔是24.00秒。

这种超时重试时间间隔对于BSD版的TCP软件实现来说，是因为500ms的定时器存在。第一次的间隔通常在5.5-6秒任意时刻超时，而第二次通常稳定在24秒。这是因为TCP在500ms之内得到系统控制的瞬间，可能系统会优先处理其它中断，从而第一次计数器减1会发生在0-500ms的任意一个时刻。而每次TCP 500ms定时器被内核调用时都会修正，于是后续稳定

tos 0x10 表示IP数据报内的服务类型，这里的值为DNS的udp查询

异常终止链接会发生什么事情？

链接一方发送复位报文来中途释放链接【正常是发送FIN】

异常释放的一端将返回RST报文段，收到的一方将终止链接，并通知应用层进行复位，接收方并不对RST报文进行确认。

什么是TCP的半关闭？

TCP的一端结束发送后，仍然能接收另外一端发送的数据。

应用场景

想仅进行一次排序的操做。流程为从客户端读取用户输入的文件，从服务端进行排序，而后客户端接收排序的结果。对于客户端来说，当文件传输完毕以后不会再发送数据，此时能够直接关闭，而服务端须要先对数据拍完序，再作回应，此时客户端要保持接收数据的能力，这样就适合使用半关闭(服务端通知客户端也可使用另外1次TCP链接，可是半关闭能够省掉多余1次的链接过程)

什么是TCP的半打开？

链接的一端已经关闭或异常终止，可是另外一端确不知道这个状况。

出现场景

客户端和服务端正在正常通讯的时候，忽然服务器断电了，这个时候客户端并不知道服务器断电，对于这种状况，若是服务器当即恢复电源再立马重启，当客户端在服务器重启以后发送数据时，服务端则回复复位标识，即TCP的标识位R设置为1，客户端收到信息，知晓链接终止

相似场景：客户使用完本身的电脑，直接把电脑电源线拔了，这时服务器并不知道客户端已经消失，后续客户端再开机又会创建新的链接，这样致使服务器会存在许多半打开的链接

若是TCP两端同时打开会怎么样？

通讯双方发送的SYN同时到达对方，且一端发送的端口和另外一端要求接收的端口同样。

出现场景

主机A应用程序使用本地端口7777，与主机B端口8888执行主动打开，主机B应用程序则使用本地端口8888，与主机A端口7777执行主动打开

报文状态变迁以下

整个过程打开须要4次报文段交换，tcp自己的设计保证，这种场景仅创建了1个链接

其它协议族可能创建两条，好比OSI运输层

若是TCP两端同时关闭会怎么样？

通讯双方都执行主动关闭。状态变化以下：

交换的报文段和正常的关闭使用的数目同样。

TCP的状体变迁过程是怎样的？

3次握手的状态变迁

链接创建超时状态变迁

同时打开状态变迁

4次挥手状态变迁

同时关闭状态变迁

收到RST的可能状态变迁

RST发生通常是接收端收到的包很明显和当前链接没有啥关系，这时候就触发RST包产生

• 因为某种未知因素，客户端发出的SYN屡次，可是服务端接收到的倒是旧的SYN，这时候客户端发出RST，服务端收到RST从新建链接

• 处于半打开状态，链接已经创建的时候，忽然客户端挂了，这时当客户端尝试再次打开链接或者服务端再次发送数据都会让服务端收到

上图为客户端CRASH而后客户端重连，下图为客户端CRASH而后服务端向客户端返回数据

从SYN_RECEVIED状态进入FIN_WAIT_1状态

此时没有须要发送的东西，队列中也没有未完成的东西须要发送，就生成一个FIN包，发送出去，断开链接

有要发送的东西，好比ack,就去创建链接

2MSL等待时间是什么？

MSL（Maximum Segment Lifetime）是报文段的最大生存时间。

生存时间是有限的，因为TCP报文段是以IP数据报在网络内传输，而IP数据报经过TTL的跳数限制，于是报文段被丢弃以前，在网络内生存时间有限

当TCP执行主动关闭并发回最后一个ACK，该链接必须在TIME_WAIT状态内等待2倍的MSL时间。

缘由：1：TCP主动关闭端发送的ACK若是丢失了，被动关闭端再次重发FIN，这时候的时间等待可以使得TCP主动关闭端发送最后的ACK不会丢失；2下次新的链接可能会复用同一个端口，若是因为网络延迟，老的数据才到，会与新数据发生混合，等待2MSL可使得老数据彻底消失

在2MSL时间段以内，定义这个链接的插口(客户端IP和端口，服务端IP和端口)，不能再被 被动断开方使用

若是服务端的链接忽然断开再立马从新启动，服务器的这个端口在2MSL时间内客户端没法链接【这里客户端是被动断开方】；同理若是是客户端本身断开，再立马使用相同的端口，在2MSL时间内去连服务器也是没法成功的【这里服务器是被动断开方】。这种场景客户端能够再随便换一个端口便可，可是服务端的通常应用端口都是固定的，容易形成麻烦

若是多个请求同时到达服务端，服务端是如何处理的？

TCP服务器会专门安排一个进程，它永远处于LISTEN状态，用来接收客户端的请求，当请求被接收时，系统中的TCP模块就会建立一个处于ESTABLISHED状态的进程

处于LISTEN状态的进程不能接收数据报文段，处于ESTABLISHED状态进程不能接收SYN报文段

伯克利TCP实现多链接处理规则为：

1. 正等待链接请求一端有一个固定长度的链接队列，队列中的链接已被TCP接受，可是应用层尚未感知
2. 应用层指明改队列的最大长度，它一般称为积压值（backlog），取值范围是0-5
3. 新链接到达时，若是链接队列有空间，TCP模块将对SYN进行确认并完成链接创建。但应用层只有在3次握手的第3次报文段接收到后才知道这个新链接
4. 新链接到达，可是链接队列没有空间，TCP模块不理会SYN，也不发回RST，若是应用层没有及时接受已被该TCP接受的链接，链接占满，客户端的主动打开最终将超时

TCP接收链接是放入链接队列，应用层接收链接是从队列中移除

队列的积压数与服务器能处理的最大链接数没有关系