【计算机网络】传输层协议TCP&TCP的3次握手4次挥手问题

在前边的TCP/IP的分层结构中，我们知道，TCP是传输层的协议，当然就是负责数据的传输，下边我就来分享TCP的一些相关内容。

1.TCP的特点：

（1）TCP是面向连接的传输层协议，也就是说，应用程序在使用TCP进行数据的传输的时候，必须先要建立连接，传输完毕之后还要进行断开连接的操作，关于这个问题，之后将会分析--三次握手四次挥手。

（2）面向字节流。所谓的流，就是流入进程或者是流出进程的都是字节序列。然而我们又知道，应用程序和进程交互的时候发送的是一个又一个的数据报，但是接收方收到的数据报不一定是和发送方发来的数据报的大小是一样的，但是最终的总的字节数是和发送方是一样的。这里就体现出一个面向字节流的概念。

（3）可靠的服务。通过TCP建立连接进行发送数据，保证数据的无差错，不丢失，不重复，而且有序到达接收方。

（4）全双工通信。意思就是，任何时候，双方可以互发数据，也不会干扰。这也就是双方都有自己的接收缓冲区所致。

（5）端到端的通信。

2.TCP报文的首部格式：

各字段代表的含义：

（1）源端口和目的端口：端口号表明唯一的网络服务，IP地址和端口号共同标识网络中唯一的一个进程。通过查看/etc/services文件，可以看到所有的well-known的端口。比如HTTP是80端口等等。

（2）序号：在TCP连接中传送的每一个字节都是按照顺序进行编号。所以，这个字段的值就是本报文段所发送的第一个字节的序号。

（3）确认号：期望收到对方下一个报文段的第一个数据字节的序号，也就是说，该编号之前的所有字节都已经正确收到。

（4）首部长度：由于 TCP的首部长度并不是固定的，所以，我们必须有一个段来表示首部长度，以便用来区分首部和有效载荷部分。这里的首部长度和IP数据报中的首部长度的含义是一样的，首部长度的值*4得到首部长度的字节数。

（5）URG：URG==1时，告诉系统该报文中有紧急数据，应该尽快传送。

（6）ACK：当ACK==1确认字段才有效，ACK==0，确认号无效。TCP中规定，当连接建立之后，所有传送的报文段的ACK都必须是1.

（7）PSH：当PSH==1时，表明发送方发了一个紧急指令并希望接收方立即回复，所以，此时就要立即创建一个报文段，把所要发送的数据发送出去 ，不需要等待整个缓冲区都满了才向上交付。

（8）RST：RST==1表示TCP连接中出现严重的查错，必须释放连接，重新进行连接。

（9）SYN：当SYN==1表示这是一个连接请求或者连接接受报文。

（10）FIN：FIN==1表示数据已经发送完毕，请求断开连接。

（11）窗口：2字节，窗口值就是用来告诉对方，发送方可以接收的最多的字节数，希望对方不要一次性发太多，造成网络堵塞。所以，窗口字段的值，表示允许对方发送数据的最大字节数。

（12）16位检验和：检验首部和数据部分。需要加一定的伪首部。通过伪首部来确认收到的数据是否和发送方发的数据是一样的。

既不上传也不下传，仅仅是为了检验和。

（13）紧急指针：只有在URG==1时，该字段才有效。它指出紧急的数据的字节数（紧急数据之后就是普通数据），也就是指出了紧急数据在报文段中的位置（即使滑动窗口为0，也可以发送紧急数据）。

（14）选项：表明TCP的首部是可变长的。如果没有选项，TCP的首部长度是20字节。

阅读完上边的各个字段的含义，细心的你可能会发现PSH和URG好像是一样的，是吗？？

其实不是的。URG只是把紧急数据放在报文的开始，然后尽快传送，放到缓冲区，如果缓冲区没有满，估计还需要等待吧。。

而PSH就是创建一个新的报文段，把要发送的紧急数据放进去，发送，如果缓冲区没有满也要发送。

在前边的叙述中，我们知道TCP要传输数据的时候需要先建立连接，发送完数据之后断开连接，那么TCP是如何建立连接和断开连接的？下边就来分析三次握手四次挥手问题。

3.三次握手四次挥手问题

建立连接的过程：

1）A主动打开连接，B被动打开连接，然后此时B就处于listen状态，等待A发出的连接请求；

2）A发送请求连接（SYN=1，seq=x），A已经进入发送请求的状态。

3）B收到A的请求，此时给A发出确认数据（ACK=1，ack=x+1，seq=y），B进入接受请求的状态。

4）A给B发出确认（ACK=1，seq=x+1，ack=y+1），说明A发送请求已经完成，连接成功。

5）B收到A的确认，说明B已经连接成功。

TCP规定：SYN=1的时候不能携带数据，但是必须消耗掉一个序号，所以，上述的发送都是会给出一个序号。

如果不是3次握手（2次握手）会怎样？

如果是两次握手，那么就是：A发送连接请求，B确认连接，此时就建立连接。

现在模拟一种情景：如果A发送一个连接请求，因网络原因在网络中滞留了很久，直到A和B释放连接之后才到达B，而B会认为这是A发送的请求连接的数据，此时B就会给A发送一个确认数据，如果是两次握手，此时就应该建立连接，然而这并不是A向B发起的连接请求，不能建立连接。如果是3次握手，A收到B的确认就不会理会，更不会给B发送数据，所以，就不会建立连接。

连接释放的过程：

分析：

A是主动关闭，B是被动关闭，A在发送断开请求的时候就关闭，B在发送完自己的数据，发送断开确认的时候才被动关闭。

1）A发送断开的请求（FIN=1，seq=u），此时A就进入终止等待1状态；

2）B收到A的断开请求之后，然后给A发送确认数据（ACK=1，seq=v，ack=u+1），此时B就进入关闭等待状态；

3）当A收到B的确认之后，进入终止等待2状态，等待B的连接释放报文。

  然而B没有发送连接释放报文，而是发送自己的数据。。（此时只允许B向A发送数据，不允许A向B发送数据，此时的TCP连接就处于一种半关闭状态）。当B发送完成。。

4）B发送连接释放报文（FIN=1，ACK=1，seq=w，ack=u+1），这里对A发送来的数据进行了两次确认。

5）当A收到释放请求之后，给B发出确认（ACK=1，seq=u+1，ack=w+1），在2MSL时间之间，都没有收到B的消息，此时A就可以断开连接了。

下边，先说一下2MSL是什么？

MSL是最长报文长度，在RFC793建议设为2分钟，2MSL就是4分钟。

这里，为什么A要等待这个时间之后才能断开连接呢？

如果A收到B的断开请求之后，给B发出确认报文在一定的时间没有被B收到，此时B就怀疑是不是自己的断开请求就没有被A收到呢。。然后B就再次重新发送断开请求，如果A收到了断开请求，就说明A的确认报文没有发送成功，此时A就会重新发送，开始计时2MSL时间。

说到这里，我们就来说一下与TCP协议有关的几种计时器。

4.四种计时器：

（1）时间等待计时器：这个就是上边所述的2MSL的时间，目的是为了保证让服务器收到客服发出的确认字段。

（2）保活计时器：这个计时器就是用来防止客户机发生故障服务器白白等待浪费资源的现象。举例来说：假设客户机与服务器已经建立好了连接，此时客户机突然出现了故障，因此服务器会等待客户机发送的数据，会一直等待吗？不是的。服务器每收到客户机发来的数据，就会重置这个保活计时器，一般设置为2小时，如果这个2小时都没有收到数据，服务器就会侦测客户机是否出现问题，多次侦测没有响应，服务器就会不再等待。

（3）超时计时器：TCP是一种可靠性传输，发送方只要一段时间没有收到接收方的确认信息，就会认为刚才发送的数据丢失了，此时就要重新发送刚才发送的数据，这个就是超时重传。要实现超时重传，就要在每发送完一个分组就设置一个超时计数器，如果在超市计数器到期都没有都到确认字段，此时继续重传；否则传输成功。 

（4）以下的持续计时器描述的部分来源于http://blog.csdn.net/jxh_123/article/details/27213439感谢作者~~

持续计时器：用于处理零窗口值的通过。若接收端的TCP要命令发送端的TCP停止发送报文段时，就向发送TCP发送一个报文段，该报文的窗口大小字段为0，称为零值窗口。发送端的TCP收到该零值窗口值报文后，就会停止向接收端的TCP发送报文，直到接收端的TCP发送一个窗口大小非0的ACK报文。若接收端TCP向发送TCP发送ACK报文，以通知其发送窗口的大小（非0）后，接收端的TCP便等待发送端发送数据，若该ACK回去的路上丢失了，则发送端的TCP并没收到ACK报文，便不会向接收端发送报文，而接收却以为自己的ACK报文发成功了，便傻乎乎的瞎等待（别忘了，ACK报文是永远不会被设置重传计时器的），这样两个人便陷入了“死锁状态”。为了防止该死锁状态的出现，TCP为发送TCP设置了一个持续计时器，一旦发送TCP收到了“零值窗口报文”，该计时器便启动。启动后，在为超时期间，若收到了接收端的非0窗口的通知，则停止该计时器；若该持续计时器超时了，则发送TCP就发送一个特殊的探测报文段，该报文段仅包含1B的新数据，该报文不需要确认，探测报文的作用在于提醒对方（目的可以记录在数据部分），重传下上次发送发送的那个ACK报文（即那个非0值窗口的报文）。

    注意：TCP规定，接收窗口的rwnd=0，也必须接收这三种报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段。

开始看TCP的3次握手4次挥手的时候，同学就给我讲了这样说一段话，我将它分享出来，结束这篇文章：

连接建立过程：

A：我喜欢你，做我女朋友吧？

B：你确定吗？

A：确定。

然后就在一起了。

连接释放过程：

A：我们分手吧。

B：好。

     说了一些伤心的话。。。

B：分就分。

A：好。