标签：UDP ACK TCP 发送 ----- 连接 服务端 客户端

TCP与UDP都工作在传输层，在程序之间传输数据，对于它们来说传输的图片，视频，语音都一样是二进制数，无所谓。

TCP面对连接，UDP面对无连接。

 

 TCP如何确保可靠传输？三次握手，传输确认、四次挥手。

 

 

三次握手

为什么是三次握手而不是两次?客户端在发送请求SYN包后，服务端收到并回复SYN+ACK包不就可以确认连接了吗？

 因为这是为了防止已失效的请求报文，突然又传输到服务端引起服务端错误。                 --------这是什么意思？

答：假设采用两次握手建立连接，客户机向服务端发送一个SYN包来请求连接，但在中途丢包了，或者网络堵塞了并没有到达服务端，然后客户端就又发送一个SYN包到服务器，服务器这次收到了，完成第一次握手，服务器发送一个SYN+ACK包给客户端完成第二次握手，连接建立。但这时候客户机发起的第一个SYN包的网络堵塞疏通了，又发送到服务端来了，服务端就会认为客户机要建立第二条连接，就又会发送一个SYN+ACK包到客户机，造成了信息的错乱，客户机要建立的是一条连接，服务器认为它想要建立的是两条连接。

三次握手的话，服务器端没有收到来自客户端最后一个ACK，就不会认为连接建立成功，所以三次握手是为了解决网络信道不可靠的问题。经过三次握手过后服务端和客户端都进入了信息传输的阶段。

 

TCP需要在不可靠的信道上保证可靠的连接，那么就要面临一些问题，一包数据可能会被拆分成几个包传输。如何保证传输的丢包问题与乱序问题？

 

 答：TCP为以上问题建立了一个发送缓存区，从建立连接后的第一个字节的序列号为0，后面每一个字节的序列号+1，发送数据时从缓存区，取一部分数据组成发送报

 

 

在其发送的TCP报文头部会附带序列号和长度，接受端在接受到，回复接受报文ACK=序列号+长度。也就是下一包的起始序列号。这样一问一答的方式，能使发送方确认发送的数据已经被对方接受。这样发送方可以把待发送的数据切割发送到对端，对端根据序列号和长度，重组出完整的数据，假设其中丢失了某些包，也可以发现，并要求发送端重传。

以上过程不区分客户端与服务端，TCP是全双工的，对于两端来说均采用以上步骤。

四次挥手

处于连接的客户端与服务端都能发起连接关闭请求。

 

如发起请求方客户端向服务端发送一个请求关闭连接FIN包，自己进入等待关闭1，这是第一挥手。

对方收到发送一个ACK包表示自己进入关闭等待状态，这是第二个挥手。

客户端收到后进入等待关闭2，服务端此时还可以发送未发送完的数据，客户端也可以接受，待服务器发送完后发送一个FIN包，进入最后确认状态这是第三次挥手。

客户端收到后回复一个ACK包进入超时等待状态，经过超时等待后关闭连接，而服务端收到ACK后就已经关闭了连接，这是第四次挥手。

 

为什么客户端需要等待超时时间？

答：这是为了确保对方已经收到ACK包，假设服务器端在发送完最后一个ACK后就关闭了连接，而发送出去的ACK包丢包了，而服务端因为长时间没收到ACK包会重新发送FIN包，去要求客户端重新发送，而客户端已经关闭了就无法收到并重发了。

 

 

 

 未完-————————————————————————————————————————————————————————————————————————

 

 图片与笔记来源哔哩哔哩视频https://www.bilibili.com/video/BV1kV411j7hA

标签：UDP,ACK,TCP,发送,-----,连接,服务端,客户端
来源： https://www.cnblogs.com/llyyyy/p/16336184.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。