python网络编程（3）——TCP三次握手四次挥手

最新推荐文章于 2024-02-12 12:52:12 发布

weixin_43940444

最新推荐文章于 2024-02-12 12:52:12 发布

阅读量674

点赞数

分类专栏： python新手入门文章标签：网络 socket python

本文链接：https://blog.youkuaiyun.com/weixin_43940444/article/details/107681687

版权

python新手入门专栏收录该内容

28 篇文章

订阅专栏

python网络编程（3）——TCP三次握手四次挥手

TCP连接的建立(三次握手)
TCP连接的释放（四次挥手）
tcp长短连接
tcp/ip 协议
- OSI与TCP/IP协议的对应关系

TCP连接的建立(三次握手)

官方式说法：

1、TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态；
/
2、TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
/
3、TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。
/
4、TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。
/
5、当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。

用自己的话来说就是：
在客户端上服务器发起连接时，是由客户端率先发起的请求，即向客户端发起连接请求报文。服务器接收到连接请求报文后，同意连接后向客户端发起确认报文，客户端收到确认报文后，再次向服务器发起确认，服务器确认后两者建立连接。
这里面的一系列动作需要消耗序列号，就像加密过的暗号，暗号对了、解码对了就可以通过。

三次握手缺一不可。尤其是最后一次握手。

假设场景：如果只有两次握手，当客户端发起第一次握手时，网络发生延迟，导致服务器没有收到连接请求，客户端再次发起第一次握手，服务器确认连接。此时因为网络延迟没能送到服务器手里的连接请求到达服务器，服务器再次确认连接，但客户端已经不需要了，这就会造成不必要的资源浪费。
如果是三次握手，再发生以上情形时，如果是由客户端确认需要连接，那服务器接先后收到两次连接请求，当两者成功建立连接后，多出的那一次连接请求报文会被确认失效，就算服务器接收到失效报文并发出确认报文，客户端已经不需要了，也就不会再向服务器发出确认，报文彻底作废。

就像怀孕中的准母亲一样，不会在怀孕期间再次怀孕。

TCP连接的释放（四次挥手）

官方式说法：

1、客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
/
2、服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
/
3、客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
/
4、服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
/
5、客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
/
6、服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

用自己的话来说就是：

客户端发出连接释放报文给服务器，并不再发送数据。（第一次挥手）

女朋友跟你提出分手，不再联系你。

服务器接收后发出确认报文，询问客户端，并进入关闭等待状态，同时客户端进入半关闭状态。（第二次挥手）

你不想分手，试图挽留，女朋友爱搭不理，你问女朋友：真的要分手吗？

客户端接收确认请求，进入终止等待状态（在这之前还需要接受服务器发送的最后的数据）。

女朋友接到询问，想分又不想分，看看你最后还有什么说法。

服务器发送连接释放报文，进入最终确认状态。（第三次挥手）

你死心了，说了些祝福的话或者啥也不说甚至用了国际祝福手势和用语。

客户端接收连接释放报文，发出确认，进入时间等待状态。（第四次挥手）

女朋友也死心了，认清事实，开始放空自己，但还没断了想法，一段时间后才断了念头。

服务器接收确认，立即进入CLOSED状态。

你真的被甩了，头也不回地走了，然后等着女朋友或者下个女朋友找上门来。

tcp长短连接

tcp短连接

在前面一章写过的tcp代码，当没有whlie True:的时候客户端和服务端只进行短暂的收发数据，然后某一方断开连接，这就是短连接。

from socket import *

# 1、创建一个tcp套接字（打开窗口）
tcp_c = socket(AF_INET,SOCK_STREAM)

# 目标信息 格式是元组
tcp_ip_port = ('192.168.56.35',9999)

# 2、连接服务器（建立连接）
tcp_c.connect(tcp_ip_port)

# 3、发送数据
send_data = input('请输入要发送的内容：')

# 4、send 发送字节流信息（主动出击）
tcp_c.send(send_data.encode('gbk'))

# 5、接收信息（接招）
recv_data = tcp_c.recv(1024)

print(recv_data.decode('gbk'))

# 6、关闭连接（关闭窗口）
tcp_c.close()

操作：

建立连接——数据传输——关闭连接…建立连接——数据传输——关闭连接

tcp长连接

跟短连接相反，当有while True:的时候，双方一直处于连接状态，不断收发数据，直到客户端发起断开连接请求。
操作：

建立连接——数据传输…（保持连接）…数据传输——关闭连接

TCP长/短连接的优点和缺点

长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。

对于频繁请求资源的客户来说，较适用长连接。

client与server之间的连接如果一直不关闭的话，会存在一个问题，

随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，

如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致server端服务受损；

如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，

这样可以完全避免某个蛋疼的客户端连累后端服务。
短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。
但如果客户请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。