TCP连接的三次握手详解.docVIP

TCP连接的三次握手详解 连接时三次握手 三次握手过程如下图所示： 整个过程可简述为如下五步： ① 服务器端，通过调用socket、bind、listen等待客户端的连接。 ② 客户端调用socket后，调用connect主动连接，它向服务器发送一个连接请 求报文段，该报文段中TCP首部中的同步位SYN(Synchronize)=1，同时选择 一个初始序列号seq=J，一般来说，SYN连接请求报文段不携带数据，只包 含一个IP头部、TCP头部及可能有的TCP选项信息。但是，它要消耗一个 序列号。然后客户端进程进入SYN_SENT(同步已发送)状态。 ③ 服务器端进程接收到客户端的SYN连接请求报文段后，它向客户端发送一 个确认报文段，该报文段中TCP首部中的同步位SYN和确认位ACK都为1， 确认号ack=J+1(表示J报文段已经收到，下次要接收的报文段序号为J+1)， 同时它也要选择一个初始序列号seq=K，同样该报文段一般也不携带数据， 要消耗一个序列号。此时服务器端进程进入SYN_RECV(同步收到)状态。 ④ 客户端收到服务端确认报文段后，它再想客户端发送一个确认报文段，该报 文段中ACK位为1，确认号ack=K+1，该报文段序列号seq=J+1。TCP标准 规定，该报文段可以携带数据，但若不携带数据则不消耗序列号，即此时， 下一个报文段序列号还是J+1，这是客户端进入ESTABLISHLED(已建立连 接)状态。 ⑤ 服务器端收到客户端的确认后，也进入ESTABLISHLED状态。 下图为用WireShark软件抓取的TCP通信过程的数据包。 客户端IP地址为：0(从第34帧数据中，我们也可以看出) 服务器端IP地址为：9 红线上方为建立连接时，三次握手过程。 红线下方为关闭连接时，四次握手过程。 两条红线中间为数据数据通信的过程，第299帧为客户端向服务器端发送一个报文段，然后第300帧为服务器端对报文段的确认报文段，我们可以看到该报文段的Len为0，所以它是不含数据的。类似的，第823帧为服务器端向客户端发送了一个报文段，然后824帧为客户端对该报文段的确认。 我们看一下第35帧的数据。 我们发现TCP头部中Flags标志中的ACK和Syn位都为1，Seq=0，Ack=1。 好，现在看第36帧，是客户端向服务器端发的确认报文段，显然其Len=0，也即它是不携带数据的，此时的Seq=1，根据我们所说的TCP标准，此报文段应该是不会占有该序列号的，也即下次客户端向服务器端发送数据的起始报文段序号还是1。那我们看看第299帧是不是如此。 由上图，我们可以看出，确实Seq=1，并且下一次报文段的Seq=7，大家可能是不是会觉得下一次的报文段Seq=2，其实，我们要理解对Seq序列号的标记是根据传输的数据(真真实实的数据，除去哪些头部的)的字节数决定的，对每一个字节的数据都必须对应一个Seq。那由Seq=1，Next sequence number=7，我们可知这个报文段这次一共传了6个字节的数据。我们看上图下面的TCP segment data发现确实是传了6字节的数据，并且由箭头所指处可知，传的是字符串“123456”，然后由图最上面的Length列可知(由截图最下面中间部分也可知)，该报文段的整个大小为60字节，而真实的数据只有6字节，也就是说其他头部信息占了54字节，那以太网(数据链路层)头部、IP头部、TCP头部各占多少呢？好，那我们来看看一个应用程序的数据是怎样由上层向下层封装的。 由下图，我们可知以太网首部为14字节，IP首部和TCP首部都为20字节，呵呵，正好54字节，当然，这里这个数字理论上说应该说是最小的情况，各个头部在某些情况下，头部可能会大于上面的值。 不信，我们看看第34、35帧的报文段Length都为66，但是真实数据Len=0，所以该报文段包含应该全部是些首部信息为66字节大于54。 由上面的分析可知，第299帧，应该是没有包含4字节的以太网尾部信息的。 好了，对于上面的分析我们告一段落，现在再来讨论一个问题，也是面试的时候，经常会被问到的. 问题1：假如第三次客户端向服务器端发送的ACK的丢失，会出现什么情况？ 问题分析：第三次客户端向服务器端发送的ACK丢失，此时客户端处于ESTABLISHLED状态，但服务器端处于SYN_RECV状态。此时可能会出现两种情况： 因为客户端处于ESTABLISHLED状态，所以它认为连接已经建立了可以发送数据了，此时如果它发送数据给服务端，但是由于服务端没有接收到ACK，它还处于SYN_RECV状态，这个时候服务器端接收到客户端发来的数据，将回应RST报文，告之Server端错误。 对于Server端，它在一段时间内没有接收到ACK报文，它将