Python学习【TCP/IP】-创新互联

TCP与UDP的区别

1.TCP是面向连接的传输协议,传输前双方需建立连接通道,而UDP可以直接传输。

2.TCP传输信息可靠,信息传输无差错,不丢失,不重复,且按序到达。UDP传输不保证可靠。

3.TCP是字节流传输(较长数据分割成数据块进行传输),而UDP是报文流传输(给多少传多少)。

4.TCP为了实现传输可靠性使用了较为复杂的算法和实现过程,不适用于实时传输,UDP实时性较好。

5.每一条TCP连接只能是点对点的,UDP支持一对一,一对多,多对一,多对多。

6.TCP占用系统资源较多,UDP相对较少。

TCP三次握手的具体过程? 并解释为什么需要三次握手?

第一次握手:客户端向服务端发出请求,发送SYN包(同步序列编号)到客户端,并进入SYN_SENT状态。

第二次握手:服务端获取到SYN包后,需要回复确认ACK,同时发送自己的SYN,并进入SYN_RECV状态。

第三次握手:客户端获取到服务端发送的ACK和SYN后,需要回复确认ACK,发送完毕后,两端同时进入ESTABLISHED(TCP连接成功)状态,完成三次握手。

分析:

TCP可视为全双工通信,分为两个通信方向:Client>>Server / Server>>Client。

第一次握手:客户端提交数据传输请求。
(C提交申请,但C自身并不知道C>>S 和S>>C是否可行)

第二次握手:服务端应答客户端,表示确认接收到客户端数据,并发出SYN,等待客户端应答。
(S对C的请求进行应答,S可确认C>>S可行,但不知道S>>C是否可行)

第三次握手:客户端应答服务端,表示确认接收到服务端数据,建立连接。
(C对S请求进行应答,C可知S>>C和C>>S均可行,S接收应答后可知S>>C可行,即可建立连接)

三次握手是对可靠传输进行确认的必要过程,完成三次握手可确保信息传输的可靠性。在两端未确认的情况下进行传输,可能会导致信息重发等问题出现。

TCP四次断开连接的过程, 并分析为什么断开需要四次?

第一步,当主机A的应用程序通知TCP数据已经发送完毕时,TCP向主机B发送一个带有FIN附加标记的报文段(FIN表示英文finish)。

第二步,主机B收到这个FIN报文段之后,并不立即用FIN报文段回复主机A,而是先向主机A发送一个确认序号ACK,同时通知自己相应的应用程序:对方要求关闭连接(先发送ACK的目的是为了防止在这段时间内,对方重传FIN报文段)。

第三步,主机B的应用程序告诉TCP:我要彻底的关闭连接,TCP向主机A送一个FIN报文段。

第四步,主机A收到这个FIN报文段后,向主机B发送一个ACK表示连接彻底释放。

分析:

同样,关闭连接前要两端都确认自己本端和对端数据传输完毕。即获取对方发送的FIN并应答(ACK)告诉对方自己获取到了对方的FIN。

第一步,A主机给发给B主机的消息传输完毕,向B发送FIN,告知B自己发送完毕,准备关闭连接。
(此时A传输完毕发出FIN,但不知道B是否发送完毕,也不知道B是否接收到自己的FIN报文)

第二步,B主机在未发送完毕的情况下接收到A的FIN,向A回复ACK且通知本机应用层,并将未发送完毕的数据继续发送完。
(B得知A发送完毕,A接收ACK后得知B接收到自己发送的FIN报文)

第三步,B主机发送完毕后,发出FIN报文,并等待A的应答(2MSL内没有收到A的应答,则重发)
(B传输完毕,但不知道A是否接收到自己的FIN报文)
(MSL指一个片段在网络中大的存活时间,2MSL就是一个发送和一个回复所需的大时间)

第四步,A收到B的FIN报文,做出ACK应答,在等待2MSL后自行关闭。
(A应答,B收到后得知A收到了自己的FIN报文,B关闭,A在2MSL内没有收到B的FIN重发,判断B已经收到了自己的ACK,A关闭)

四次挥手可以看作是改良版的三次握手,只不过在第二次握手时考虑到B端数据没有发送完毕的情况,因此ACK和FIN分两次进行发送,变成了四次。

另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。

创新互联是一家专业提供城厢企业网站建设,专注与网站制作、成都网站建设H5建站、小程序制作等业务。10年已为城厢众多企业、政府机构等服务。创新互联专业网络公司优惠进行中。
网站栏目:Python学习【TCP/IP】-创新互联
标题URL:http://abwzjs.com/article/ccigcg.html