TCP三次握手

TCP三次握手

         对于学习网络的人来说，TCP的三次握手的过程可以说是最熟悉不过的了，但是，最近在看网络的书的时候，发现之前理解的TCP的三次握手和四次挥手是多么的浅显，有机会再次学习，就整理下来，作为复习和参考使用，让自己对TCP有一个更深层次的认识。

         作为基础，TCP报文的基本格式在这里就不再过多的说明了。（总之很重要）最近一段时间会进行整理，并对其中的一些细节进行研究。这篇主要说明TCP的三次握手的过程。

         我们知道，TCP是基于字节流进行传输数据的，而且采用的是客户服务器的模式，（即C/S模式），这种模式的好处在于，可以通过客户端请求，服务端提供服务的方式进行通信，在网络中有很多的服务都是采用这种方式进行数据通信的，比如FTP，比如HTTP这些应用层的协议。

         下面说明连接建立的过程：

1.       最初始的状态是，客户端和服务器端主机的TCP进程都是处在一个CLOSED（关闭）状态的，这里就有两种打开连接的方式，对于客户端来说，需要主动打开连接，而服务器端是被动打开连接的。

2.       B的TCP服务器进程首先创建传输控制块（TCB：存储了连接中的重要的信息，包括TCP的连接表，发送和接收的缓存的指针，到重传队列的指针，当前的发送序号和接收序号），准备接受客户端的连接请求，（从这里可以看出，TCP的连接建立过程中是服务端先打开连接的。）然后服务器就进入了LISTEN（收听）状态，等待客户端的连接请求。（作为服务端是提供服务的，所以在提供服务的过程中，服务端不知道客户端什么时候会发起请求，所以它会一直保持着这种LISTEN状态，等待连接的到来。）

3.       如果这个时候客户端主机想要创建一个连接，它首先也会创建一个传输控制块（TCB）然后向服务端发送请求报文段，这时候首部中的同步位SYN位置为1，同时选择一个初始的序列号seq=x。（这个序列号一般是操作系统给出的，可能是与时间相关，可能是随机的序号。）TCP规定了在SYN为1的时候，也就是SYN的报文段是不能携带数据的，但是要消耗掉一个序号，这个时候客户端进入了SYN-SENT（同步已发送）状态。

4.       当服务端收到了来自客户端发来的请求时，如果同意建立连接，则向客户端发送确认，在确认报文中应该把SYN和ACK位都置为1，确认号为ack=x+1，同时也为自己产生一个序列号为seq=y，注意这时的报文也不能携带数据，但是同样的要消耗掉一个序列号，这时的TCP进程进入SYN-RCVD（同步收到）状态。

5.       客户端收到服务端的确认后，还要向服务端发送确认，确认报文ACK位置为1，确认号为ack=y+1，而自己的序列号为seq=x+1。TCP的标准规定了，ACK报文段可以携带数据，但是如果不携带数据的话，是不消耗序列号的，在这种情况下的话，下一个将要发送的数据报文的序列号还是seq=x+1。然后客户端进入ESTABLISHED（已经建立连接）状态。

6.       当服务端收到客户端发来的确认后，就进入了ESTABLISHED状态。

 

说明：

         为什么客户端也要发送一次确认呢？

         可能发生这样的情况，客户端发送的一个请求在网络中滞留了很长的时间，由于服务端没有收到请求不会确认，客户端会重新发送请求，等到服务端收到这个请求后，确认并回复客户端，客户端再发送给服务端确认，然后建立了一个连接，但是这时，滞留在网络中的另外的那个请求到达了服务端，服务端以为客户端又想建立一个连接，于是给出了确认，但是，这个请求是没有用的，如果不使用三次握手的话，这样的请求就建立了，但是客户端并不会发送数据，这样在服务端就会一直保持着这条连接，从而浪费了资源，于是就要让客户端在发送确认，如果确认是想要建立连接，服务端再打开连接准备通信，否则就不会打开这个链接（进入连接建立状态）

         我们平时总会看到这样的比喻：

         第一次握手（a->b）：你好，我是a，能听见我说话吗？

         第二次握手（b->a）：听到了，我是b，你能听见我说话吗？

         第三次握手（a->b）：听到了，我们可以聊天了。

这个比喻也是很形象了。