zoukankan      html  css  js  c++  java
  • TCP与UDP协议必知必会

    TCP协议

    一个工作在传输层的传输控制协议,面向连接、可靠的流式协议,HTTP协议建立在TCP基础上。每个TCP报文,实际在网络层进行封装成IP数据报,会进行IP分片(受限于MTU)。

    头部(20字节)

    6个标识位:

    URG:表示紧急指针(16位)是否有效;

    ACK:表示确认号是否有效,即是否为确认报文段;

    PSH:表示接收端应该立即从缓冲区读走数据;

    RST:要求对方重新建立连接,携带它的成为复位报文段;收到RST报文的一段应该关闭连接或者重新连接。(3种情况见后文:访问不存在端口,)

    SYN:请求建立一个连接,称为同步报文段;

    FIN:通知对方我方要关闭连接了,结束报文段。

    复位报文段的3种情况:

    1. 访问不存在端口;

    2. 异常终止连接;一旦向对方发送复位报文段,对方的发送数据将被丢弃(可以使用socket选项SO_LINGER来发送);

    3. 处理半打开连接:服务器或者客户端关闭或者异常终止了连接,而对方并没有收到结束报文段,此时一方就还维持着原来的连接,这种状态称为半打开状态。此时半打开的一方依然向对方发送数据,对方将会回应一个复位报文段,使其重新连接或是关闭连接。

    诸多特性保证传输的可靠性

    1. 超时重传机制:发送报文后启动定时器等待对端的确认,超时未收到确认就重新发送报文,以免报文丢失;

    2. 流量控制机制:滑动窗口协议,在双方首发数据时,都维护有一个发送/接收窗口,大小动态变化,发送端每发送一组数据就要等待确认,直到收到确认,窗口方可右移继续发送其他报文段;

    3. 拥塞控制机制:采用慢开始、拥塞避免、快重传和快恢复,来实现拥塞控制。(后面详细叙述)

    4. 全报文校验机制:保持首部和数据的16位校验和(就存在20字节首部中)接收端拿到后对报文重新计算校验和,二者比较,检验变化。校验不通过就丢弃报文,不进行确认,希望发端超时重传。

    5. 收到确认:发送端每发送一个报文都要收到接收端的确认(ACK)才算发送成功。

    典型的TCP服务器工作模式

    其中涉及到的关键点,半连接、2MSL都在图中有说明。此外,拥塞控制也十分重要:

    补充:MSL(maximum segment lifetime),一个报文段在网络中的最大生存期。

    MSS与MTU

    MSS(maximum segment size)最大的报文长度,不得超过链路层MTU(maximum thransfortion unit)最大可传送单元,在以太网中一般是MTU(1500),MSS(1500-20-20=1460)要减去TCP和IP首部长度。

    TCP拥塞控制

    慢开始

    每个连接维持两个变量,cwnd(拥塞窗口)ssthresh(慢启动门限值,一般是滑动窗口的一半),cwnd表示单次可以发送到网络上的报文段个数,开始时置1,每收到一个确认就+1,所以它呈指数式增长,“慢开始并不慢”,但他可以减缓发送速率。cwnd达到门限ssthresh时,开始执行拥塞避免算法;

    拥塞避免

    达到门限值后cwnd开始加性/线性增长,最多每次增加1个报文段。如果发生超时,那么不一定该分组就丢失,但网络肯定发生了堵塞,那么ssthresh减半,cwnd置1,以减少发送速率,重新开始慢启动算法;

    快重传和快恢复

    如果连续收到3次重复的ack,有理由相信传输过程中有分组丢失了,我们要立即重传,并将ssthresh职位cwnd一半,cwnd置为ssthresh+3MSS(TCP/IP详解 卷一),并开始执行拥塞避免,而非慢启动算法,这就是快恢复。

    为什么我们要执行拥塞避免而不是慢启动呢?

    原因时我们连续收到了3个ACK说明该分组丢失了,但是其后的分组正常到达并由收端缓存了,所以我们应该立即重传丢失分组,且不降低放速率。

    TCP编程范式

    服务端:sbla socket() -> bind() -> listen() -> accept() -> read()/write() ... ->close() -> listen() ...

    客户端:socket() -> connect() -> read()/write() ... close()


    UDP协议

    一个工作在传输层的用户数据报协议,无连接、不可靠的,基于报文的协议。它不保证交由TP分片封装的数据一定可达,也有全报文(首部和数据)检验和保证数据的安全性。(似乎看起来不能用的样子,比起TCP差远了?)

    头部(8字节,注定它没有TCP那样复杂)

    UDP没有那么多的特性,不多说。

    UDP服务器范式

    服务端:socket (填充addr信息)-> bind() -> recv()/send() ...

    客户端:socket(填充服务端IP&port信息) -> connect() -> send() -> recv() ...

    TCP和UDP的比较

    1. 有无连接;TCP面向连接,UDP无连接;

    2. 可靠与否;TCP可靠(由超时重传,拥塞控制,滑动窗口等支持),UDP不可靠;

    3. 开销: 首部TCP20字节,UDP8字节, TCP还要在内核中维持由数据结构来存储连接的状态、定时器和读写缓冲区,UDP有读写缓冲区,但不需要存储状态的定时器。

    4. 速度;TCP无疑要慢

    5. 编程方式;TCP较复杂,UDP简单

    6. 安全性;TCP涉及的部分太多,容易受到攻击,UDP涉及环节少,保证奇安全性较为容易,不易受到攻击。

    7. 连接:TCP一对一建立连接,而UDP适用于多播可广播

    8. 发送/接收方式:TCP发送端的每次写操作(sendto)和接收端的读操作(recvfrom)没有任何数量关系(流式传输,多个TCP写操作可能会被分成多个TCP报文,接收端怎么读也取决于应用程序),而UDP则是一次写就封装成一个完整的报文(携带大小)发送到接收端缓冲区,接收端必须要及时的进行读取,否则就会丢包(慢服务器会经常发生),另外缓冲区不够还会发生截断。

    使用那个?

    要快而能容忍丢包的情况,使用UDP;比如视频/音频聊天。

    严格要求传输数据的完整性,不允许丢包,能容忍较低素的的使用TCP。比如文件传输。

  • 相关阅读:
    itchat 监控微信好友撤回消息
    JAVA学习笔记(持续更新)
    go-gob序列化/反序列化与读写文件性能对比测试
    go-单元测试
    如何防范常见的Web攻击-转载
    go-读写json文件
    有关python&&c++的散碎的一些知识点_随时更新
    C Primer Plus 嵌入式裸板程序开发
    大论文格式总结(word2013)
    版本控制系统git和svn
  • 原文地址:https://www.cnblogs.com/yocichen/p/11314019.html
Copyright © 2011-2022 走看看