【详解】计算机网络从总到细——UDP与TCP

重点协议TCP与UDP

1. 认识传输层的两个协议

  • 传输层功能: 为相互通信的应用进程提供逻辑通信

  • TCP(Transmission Control Protocol,传输控制协议) :需要将要传输的文件分段进行传输,在传输之前需要建立会话,他的传输过程是可靠传输,同时要进行流量控制;[QQ传文件]

  • UDP(User Data Protocol,用户数据报协议):一个数据包就能够完成数据通信,不分段,也不需要建立会话,不需要流量控制,是一种不可靠传输;[DNS域名解析;QQ聊天]

  • 查看会话:netstat -n

  • 查看建立会话的进程:netstat -nb

  • 查看服务侦听的端口:netstat -an

  • 测试到远程计算机某个端口是否打开 :telnet 39.99.188.117 8080

2.传输层协议和应用层协议之间的关系

  • 常见的应用层协议使用的端口
    • http=TCP+80
    • https=TCP+443
    • RDP=TCP+3389
    • ftp=TCP+21
    • SMTP=TCP+25
    • 共享文件夹=TCP+445
    • POP3=TCP+23
    • telnet=TCP+23
    • SQL=TCP+1433
    • DNS=UDP+53

3.服务和应用层协议之间关系

  • 服务使用TCP或UDP的端口侦听客户端请求
  • 客户端使用IP地址定位服务器使用目标端口定位服务
  • 可以在服务器网卡上设置只开放必要的端口实现服务器网络安全

4.UDP

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uW4V1v0A-1591196440671)(C:\Users\apple\AppData\Roaming\Typora\typora-user-images\image-20200419214643600.png)]

16位UDP长度,表示数据报(UDP首部+UDP数据)的最大长度。

如果校验和出错,就会直接丢弃

  • 特点:不安全但是效率高
    • 无连接
    • 不可靠:没有确定应答机制,没有超时重传机制,也没有连接管理机制
    • 面向数据报:最大发送64k
      • 应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并;、
      • 用UDP传输100个字节的数据:
        • 如果发送端调用一次sendto, 发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom, 每次接收10个字节;
    • UDP没有发送缓冲区,只有接收缓冲区:
      • UDP没有真正意义上的 发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作;
      • UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了, 再到达的UDP数据就会被丢弃;
  • 基于UDP的应用层协议:
    • NFS: 网络文件系统
    • TFTP: 简单文件传输协议
    • DHCP: 动态主机配置协议
    • BOOTP: 启动协议(用于无盘设备启动)
    • DNS: 域名解析协议

5. TCP

  • 协议格式:

    在这里插入图片描述

    • 源/目的端口号:从那个进程来,到那个进程去;
    • 32位序号/32位确定号:和 TCP 的 ACK 机制有关,发送端给数据进行编号,接收端收到数据后确认收到哪些编号的数据。
    • 4位TCP报头长度:表示该TCP头部有多少个32位bit(有4个字节);所以TCP头部最大长度是15*4=60
    • 6位标志位:
      • URG:紧急指针是否有效
      • **ACK:**确认号是否有效
      • PSH:提示接收端应用程序立刻从TCP缓冲区把数据读走
      • RST:对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
      • **SYN:**请求建立连接; 我们把携带SYN标识的称为同步报文段
      • **FIN:**通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段
    • 16位窗口大小:
    • 16位校验和:发送端填充,CRC 校验,接收端校验不通过,则认为数据有问题。此处的检验和不光包含TCP首部,也包含TCP数据部分。
    • 16紧急指针:略
    • 40字节头部选项:略
  • 特点:

    • 有连接
    • 可靠的
    • 面向字节流
    • 具有接收和发送缓冲区
  • 确定应答机制(ACK):序号+确定序号实现

    • 生活案例理解确定应答机制

通常,两个人对话时,在谈话的停顿处可以点头或询问以确认谈话内容。如果对方迟迟没有任何反馈,说话的一方还可以再重复一遍以保证对方确实听到。 因此,对方是否理解了此次对话内容,对方是否完全听到了对话的内容,都要靠对方的反应来判断。网络中的 “确认应答” 就是类似这样的一个概念。当对方听懂对话内容时会说: " 嗯 ",这就相当于返回了一个确认应答(ACK)。而当对方没有理解对话内容或没有听清时会问一句 `` 咦?” 这好比一个否定确认应答
在这里插入图片描述

  • TCP将每个字节都进行了编号,既为序列号

  • 每个ACK都带有对应得确认序列号,意思是告诉发送者,我已经收到那些数据;下一次你从什么地方开始

  • 超时重传机制:系统基于TCP协议实现,动态计算报文的最大生存时间(MSL),超时时间设置为2MSL

    • 作用:超过超时时间,表示丢包(两种情况,如下),需要重新发送数据报(系统中发送缓冲区保存有数据,可以重发)

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aOT6GMqH-1591196440674)(C:\Users\apple\AppData\Roaming\Typora\typora-user-images\image-20200419230335443.png)]

    • 主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B;
    • 如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发;、

    但是,主机A未收到B发来的确认应答, 也可能是因为ACK丢失了;

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Kjspdv43-1591196440676)(C:\Users\apple\AppData\Roaming\Typora\typora-user-images\image-20200419230522261.png)]

    • 因此主机B会收到很多重复数据. 那么TCP协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉.
      这时候我们可以利用前面提到的序列号, 就可以很容易做到去重的效果.
  • 连接管理机制:

    • 在正常情况下, TCP要经过三次握手(红色)建立连接, 四次挥手(蓝色)断开连接
    • **!**注意:建立连接都是单方向的连接

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tMqN8KW0-1591196440678)(C:\Users\apple\AppData\Roaming\Typora\typora-user-images\image-20200419233249388.png)]

    • 三次握手:(建立连接)

      1. 客户端的协议栈向服务器端发送了 SYN 包,并告诉服务器端当前发送序列号 j,客户端进入 SYNC_SENT 状态;
      2. 服务器端的协议栈收到这个包之后,和客户端进行 ACK 应答,应答的值为 j+1,表示对 SYN 包 j 的确认,同时服务器也发送一个 SYN 包,告诉客户端当前我的发送序列号为 k,服务器端进入 SYNC_RCVD 状态;
      3. 客户端协议栈收到 ACK 之后,使得应用程序从 connect 调用返回,表示客户端到服务器端的单向连接建立成功,客户端的状态为 ESTABLISHED,同时客户端协议栈也会对服务器端的 SYN 包进行应答,应答数据为 k+1;
      4. 应答包到达服务器端后,服务器端协议栈使得 accept 阻塞调用返回,这个时候服务器端到客户端的单向连接也建立成功,服务器端也进入 ESTABLISHED 状态。
    • 四次挥手:(断开连接)

      TCP 连接终止时,主机 1 先发送 FIN 报文,主机 2 进入 CLOSE_WAIT 状态,并发送一个 ACK 应答,同时,主机 2 通过 read 调用获得 EOF,并将此结果通知应用程序进行主动关闭操作,发送 FIN 报文。主机 1 在接收到 FIN 报文后发送 ACK 应答,此时主机 1 进入 TIME_WAIT 状态

      • 为什么要ACK与FIN分开发送?服务器没有继续发FIN包给客户端。
        • 服务器为什么不发FIN,可能是业务实现上的需要,现在不是发送FIN的时机,因为服务器还有数据要发往客户端,发送完了自然就要通过系统调用发FIN了
    • ClOSE_WAIT状态:服务端程序没有调用close方法,导致出现大量的连接处于CLOSE_WAIT状态,代表半关闭,是一种bug,只需要加上对应的 close 即可解决问题.

      • 关于 “半关闭” , 类似男女朋友分手
    • TIME_WAIT状态:

      • 为啥不能设置为CLOSED? 因为低4次ACK响应报文时可能丢包,导致服务端无法关闭连接,需要服务器重新发送FIN请求
      • **为啥是2MSL?**返回ACK传输时间+服务端重新发送FIN的传输时间
  • 滑动窗口:

    • 窗口大小指的是无需等待确定应答而可以继续发生数据的最大值。假如窗口为n段
      • 依赖ACK响应报文中的窗口大小字段
      • 依赖拥塞控制窗口大小
    • 收到第一个ACK,滑动窗口向后移动,继续发送第n+1段的数据
    • 操作系统内核为了维护这个滑动窗口,需要开辟发送缓冲区来记录当前还有那些数据没有应答;只有确认应答过的数据,才能从缓冲区删掉
    • ACJ响应报文中,携带下一个序号是多少。---->表示在此序号之前的所有数据都已经接收到、
    • 窗口的滑动:
      • 依赖ACK响应报文中的下一个序号进行滑动,而下一个序号是多少,又依赖接接收到连续报文的最大序号。
  • 流量控制:

    • 接收端:通过TCP协议头中的“窗口大小”字段,告诉发送端,发送数据的大小。
    • 目的:接收端接收能力有限,为了防止接收缓冲区被打满,再接收数据直接丢弃。使用窗口大小可以告诉发送端发送数据的大小。
  • 拥塞控制:

    • 因为网络上有很多的计算机,可能当前网络状态就已经比较拥堵,在不清楚当前网络状态下,贸然发送大量的数据,是很有可能引起雪上加霜的
    • TCP引入慢启动机制,先发少量的数据探探路,摸清当前网络拥塞状态,再决定按照多大的速度传输数据。
    • 原理:
      • 拥塞窗口初始值设为1,以慢启动指数级增长的方式,达到一定阈值变为线性增长的方式
  • 延时应答机制

    • 原理:接收到多个数据段时,不针对每条数据报响应ACK,而是延迟一定时间,这样接收缓冲区数据很快被处理,可用空间更大,返回窗口大小字段就可以设置的更大,使网络吞吐量更大,传输效率更高。
  • 捎带应答:

    • 如果服务端也要传输数据到客户端,可以和ACK结合起来一起发送,这就叫捎带应答
  • TCP安全机制:

    • 响应应答,超时重传,连接机制,流量控制,拥塞控制
  • TCP性能机制:

    • 滑动窗口,延迟应答,捎带应答
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章