ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

TCP vs UDP

2021-07-24 10:04:19  阅读:169  来源: 互联网

标签:UDP 重传 握手 TCP 四次 vs 数据 连接


TCP,Transmission Control Protocol,传输控制协议。面向连接、可靠、基于字节流。牺牲效率保证传输的正确,应用层:FTP、HTTP、SMTP、POP3等协议为了保证传输正确都基于TCP协议。

UDP,User Datagram Protocol,用户数据报协议。无连接、不可靠、基于报文。没有可靠性保证但效率非常高,通常用于实时数据传输,应用层:NFS、TFTP、DHCP、DNS等协议为了能更快传输都基于UDP协议。基于UDP的文件传输系统仅适用于传输小文件,因为大文件有丢失的风险。

TCP

    • 面向连接的

      • 客户端和服务端,通过三次握手产生一对一连接(开辟资源),即一个连接中的所有数据来自同一台主机,数据传输后通过四次挥手断开连接(释放资源)。
      • 三次握手
      • 四次挥手
      • Q:为什么采用三次握手而不是两次握手or四次握手?
        • 这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致。
        • 三次通信是理论上的最小值,能够分别以客户端、服务端的视角确定上行、下行信道可用,四次握手会产生冗余引起资源浪费。
        • 若采用两次握手,当服务端收到因网络延迟等原因导致的断开连接后的用户端延迟包,将会重新建立连接等待用户数据,而用户端因已断开连接不会发送数据,导致服务器资源被占用无法释放。
      • Q:为什么采用四次挥手?
        • 为了避免一方请求停止,另一方仍有数据需要发送的情况。
        • 四次挥手由两部分组成:①A-->B:A已经没有数据要发送了,如果B有数据要发A还接收。②B-->A=B也没有数据要发送了,彻底释放资源。
    • 可靠的

      • 连接建立过程可靠。采用三次握手和四次挥手的连接建立/释放确认机制。
      • 不丢包保证。
        • 重传机制。采用超时重传和快速重传两种方式保证不丢包。
          • 超时重传。发送方根据应答中的数据往返时间RTT动态计算RTO,若重传时间将以指数倍增长,在Linux中是以500ms为基数的整数倍,重传累计一定次数后判定链路异常,强行关闭连接。
          • 快速重传。含序号的ack应答,未收到应答序号的数据包无需等待超时立即重传。
        • 流量控制机制。ack中含有接收端的缓冲区剩余大小。避免因缓冲区满引起的丢包。
        • 拥塞控制机制。慢开始+拥塞避免+拥塞后乘法减小。
      • 数据正确保证。校验和为必选字段。
      • 拥塞控制过程
    • 基于字节流的

      • 将应用层的数据看做无结构字节流来发送,使用缓冲区存储

 

 UDP

    • 无连接的  

      •   采用IP+Port的形式进行数据传输,即同一主机可能收到来自不同发送方的数据。

    • 不可靠的

      •   没有ack、不一定有校验(校验和为可选字段)、没有传输顺序保证和流量控制字段
    • 基于报文的

      •   没有缓冲区,收到的应用层报文数据直接加包头给网络层。

标签:UDP,重传,握手,TCP,四次,vs,数据,连接
来源: https://www.cnblogs.com/filletnotfish/p/15054504.html

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

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有