图解TCPIP---第六章---传输层TCPUDP

哈哈哈哈哈哈哈哈

TCPIP识别一个进行通信的应用需要5大要素

• 源IP地址
• 目标IP地址
• 源端口
• 目标端口
• 协议号

---

0-1023 知名端口号
1024-49151 这些端口被正式注册了 但是可以用于任何通信
49152-65535 操作系统动态分配的端口号
一些知名端口号如下

• 20 ftp-data File Transfer [Deafult Data]
• 21 ftp File Transfer [Control]
• 22 ssh
• 23 talent
• 25 smtp Simple Mail Transfer Protocol
• 43 nicname Who Is
• 53 domain Domain Name Server
• 80 http
• 101 hostname NIC Host Name Server
• 443 https

UDP

常被用于以下几个方面

• 包总量比较少的通信 DNS SNMP等
• 视频 音频等多媒体通信
• 限定于LAN等特定网络中的应用通信
• 广播通信(广播 多播)

TCP

确认应答 ***

TCP通过检验和 *** 确认应答 重发控制 连接管理 窗口控制 等 机制实现可靠传输

确认应答ACK acknowledgement
否定确认应答 NACK negative acknowledgement

• Q1 发送端发送数据后会等待对端的确认应答

  • 一定时间未等到确认应答 发送端认为数据已经丢失 重发
    • 未收到数据也可能是返回的确认在中途丢失
    • 也有可能是对端的确认延迟到达
  • 发送端按照机制重复即可但是对接收端可能重复收到数据 简直就是灾难 需要处理这种情况

• A1 需要一种机制 能识别是否已经接收数据 能判断是否需要接收

  • 上述确认应答处理 重发控制 重复控制 等等 功能都可以通过***实现 ***是按顺序给发送数据的每一个字节(8位字节)都标上号码的编号
  • 如下图

  

超时重发

• Q1 超时时间如何定义
• A1 最好找到一个 确认应答一定时间内一定能在这个时间段内返回
• Q2 TCP要求不论处在何种网络都提供高性能通信 并且无论网络拥堵情况发生何种变化 都必须保持这一特性
• A2 每次发包时都计算往返时间及其偏差 往返时间和偏差(RTT时间波动的值 方差)相加 超时重发时间就是这个和在大一丢丢的
• A3 在BSD的Unix以及Windows中 超时都是按0.5s为单位 偏差的最小值也是0.5 所以最小的重发时间时1s
• A4 数据被重发之后若还是收不到则再次发送 超时等待时间会2倍 4倍函数延长 数据也不会无限反复的重复 到达一定的次数后如果仍没有任何确认应答 则会判断网络或对端主机异常 强制管理连接并通知应用程序
• 如下图

连接管理

三次握手 四次挥手

MSS最大消息长度
TCP在传送大量消息时 是以MSS进行分割 重发也是也MSS为单位
MSS是在三次握手时计算出来的 在发送SYN请求时会在TCP首部写入MSS选项 会在两者中选一个比较小的值投入使用

窗口

为每个数据包进行确认应答的缺点是包往返时间越长网络的吞吐量越差
引入窗口概念 窗口的滑动如下

窗口控制和重发控制如下图 P211

流控制

窗口大小这个字段是由接收端控制的 TCP首部中有一个字段通知窗口大小 具体过程如下

拥塞控制 P213

通信刚开始就发送大量数据 可能存在隐藏问题
在网络拥堵时 如果突然出现一个较大量的数据可能导致网络瘫痪
TCP为了防止该问题 在通信一开始便会通过一个慢启动算法得出的数值对发送数据量进行控制
定义了一个拥塞窗口的概念

提高网络利用率的规范

• Nagle算法 尽在下列任意一种条件满足才能发送数据 这个算法可能导致某种程度的延迟因此在窗口系统(X Window System)以及继续控制等领域中使用TCP时往往会关闭该算法的启用
  • 已发送的数据全部都已经收到确认应答
  • 可以发送最大段长度MSS的数据时
• 延迟确认应答
  • 每次都立刻回复确认应答的话 可能会返回一个较小的窗口(因为刚接收完数据 缓冲区已满)在流控制一节可以看到接收端可以控制窗口大小
  • 延迟机制如下
    • 在没有收到2x最大段长度的数据为止不做确认应答(根据操作系统不同 有时不论数据大小 只要收到两个包就即可返回确认应答的情况) 总而言之就是各种机制延迟确认应答
    • 在其他情况下 最大延迟0.5s发送确认应答 很多操作系统设置为0.2s 延迟超过0.5时很有可能导致重发数据 这个时间越小 CPU的负荷越高性能也下降 时间越大越有可能触发发送主机的重发处理
• 捎带应答
  • TCP的确认应答和回执数据一起返回通过一个包发送
  • 比如电子邮件协议的SMTP POP 文件传输协议FTP的连接控制部分等
  • 没有启动延迟确认应答(即接收数据后立刻返回确认应答)是无法实现捎带应答的
  • 因为捎带必须等待应用程序处理完数据并将作为回执的数据返回时才能进行捎带 哈哈哈

其他传输层协议 P218

• UDP-Lite
• SCTP
• DCCP
• 等等

UDP-Lite

• 基于UDP的通信中 检验和出现错误 所收到的包将全部丢弃 然而现实中有些应用在面对这种情况不希望丢弃
• 如果将UDP中的检验和设置为无效那么即使数据的一部分毁坏也不会将整个包废弃 不过这个方法并不好 如果是IP首部中的IP地址被破坏或者端口号被破坏等等会产生严重后果
• 为了解决这些问题 UDP-Lite出现了
• UDP-Lite计算校验和的范围可以由应用自行控制 有这样的机制可以只针对不允许发生错误的部分进行校验和的价差

UDP格式

这个没啥好说的

TCP格式

TCP中没有包长度和数据长度的字符串

• 数据偏移 表示TCP所传输的数据部分应该从TCP包的哪个部分开始计算 可以理解为TCP首部长度
• 控制位 8位大小 每一位都有其意义 P223
• 紧急指针只有在URG控制位为1时有效 P225
• 可选项 P225

TCP UDP 计算校验和伪首部