标签：UDP ACK 笔记 发送 TCP 序列号 连接 服务端

TCP/UDP学习笔记

相同点：

1.都工作在传输层

2.都在程序之间传输数据（二进制文件），可以是文件、视频、图片等

不同点：

TCP：面向连接（握手挥手）、完整可靠（丢包重发）、顺序（序列传输）

三次握手（建立连接）

为什么三次握手而不是两次握手？

防止已失效的SYN报文突然传到服务器引起错误。（解决网络信道不可靠问题）

SYN包在某一网络节点阻塞，滞留一段时间后到达服务端，此时服务端收到两个SYN包，误认为两个连接，而客户端人为只有一个连接

传输确认（全双工，客户端服务端均采用此机制）

1.TCP为每一个连接建立发送缓冲区，每字节序列号增加1

2.发送报文时，由序列号、长度和部分数据内容组成发送报文

3.接收报文时，需要回复ACK，ACK = 序列号 + 长度 =下一包起始序列号 （发送端可以发送连续多包数据，接收端只需要回复一次ACK）

4.丢包重发：比如丢失了100-199 这100个字节，接收端向发送端发送ACK = 100，发送端收到后重发

四次挥手（关闭连接）

为什么客户端需要超时等待（TIME-WAIT）？

为了保证服务器收到ACK包，一旦ACK包在网络中丢失，服务端将一直停留在最后确认状态，会重发FIN包，客户端会响应这个FIN包重发ACK包，并刷新超时时间

UDP：非连接、不可靠（即发即忘）、网络开销少、实时性强

隧道网络：UDP应用场景

参考视频：https://www.bilibili.com/video/BV1kV411j7hA?vd_source=a7311bbda5c9123be5ab119dcdea3e5c

标签：UDP,ACK,笔记,发送,TCP,序列号,连接,服务端
来源： https://www.cnblogs.com/cwBug/p/16587487.html

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