TCP连接的建立和断开

预备知识

TCP是向应用层提供可靠的传输服务。TCP的下层服务是IP层，而IP层提供的是不可靠的服务。
同时TCP的服务是点到点的（port到port），IP是端到端的（主机到主机）。


TCP头部的一些字段要知道。

源端口号，目的端口号
序号
确认号
连接建立和断开的字段（SYN，FIN，RST）
接收窗口

序号：开始随机产生一个数（防止有相同的序号），之后下一个序号 = 上一个序号 + 上一个数据的长度。
应用层交付的数据可能大于MSS的，所以需要对数据进行分片。
确认号：确认数据报是否成功接受到，确认号 = 收到的序号 + 1

连接建立

怎样才算连接建立？

像UDP，客户端知道目的端的IP和端口，就可以把数据发送的目的端。
TCP同样是发送数据，但是需要建立连接后才能发送数据。

TCP是为了向上层提供有序，无差错的数据，所以需要建立连接。

连接建立就像初始化一样。我们有了固定的规则，但是变量没有值。（比如序号，接收窗口等）

这样客户端要告诉服务端，客户端的情况；服务端要告诉客户端的情况。从这个角度来说，我们两次的握手就可以建立连接了。

为什么连接建立都是三次握手呢？

我们先来看看两次握手为什么不行。

网络是不稳定的，会出现高延迟，数据报的丢失。客户端在时间t1向服务端发送连接建立请求。客户端在时间t3才接收到服务器的应答。
(t1, t3)这个时间段已经超过t1时间的设置的超时时钟，导致客户端在时间t2再次向服务端发送请求。

上述情况中多了连接的建立次，这会导致服务端压力增大。

服务端对t1时刻数据报的应答，客户端在（t2，t3）之间接收到。那么客户端有两个连接，就需要发送两个相同的数据报。这样效率低下。

这就需要三次握手

解决半连接和接收老数据问题

当客户端三次握手建立好连接后。中间可以能会出现，客户端再次请求连接。但是服务端应答的确认号A是之前使用过的了。客户端在最后一次的握手，所期待的确认号不是A，所以这次连接会被拒绝掉。这样可以解决客户端发送重复的数据报（在没有超时的情况下）。

序号，客户端和服务端都会自己随机一个初始值。

连接断开

TCP是全双工的，两个方向都要断开。客户端和服务端都可以发起断开请求，但是大多数都是客户端发起断开请求。

1、客户端到服务端方向的连接断开。

这时服务端向客户端发送数据，客户端还是能收到。现在处于半关闭状态。

2、服务端到客户端方向的连接断开

但是还没有正真的断开连接，因为客户端需要等待2*max segment lifetime（报文段最大生存时间）之后才会关闭连接。

TIME_WAIT状态

TIME_WAIT状态存在的原因：

1、可靠地终止TCP连接

2、保证让迟来的TCP报文段有足够的时间识别并丢弃

当客户端对服务器断开连接的请求的应答报文丢失。如果客户端已接受到服务端的断开请求，客户端就认为连接断开了。那么对于之后服务端的重复发送，不再做任何的应答，这样的断开连接是失败的。所以在接受到服务端的断开请求后，客户端还有维持2*max segment lifetime时间之后才会关闭服务。在这段时间里，能最大限度的保证连接的断开。