| UDP | TCP | |
|---|---|---|
| 全称 | 用户数据报协议 | 传输控制协议 |
| 英文 | User Datagram Protocol | Transmission Contorl Protocol |
| 不需要先建立连接 | 提供面向连接的服务 | |
| 面向报文的 | 面向字节流的 |
| 应用 | 应用层协议 | 运输层协议 |
|---|---|---|
| 名字转换 | DNS 域名系统 | UDP |
| 文件传送 | TFTP 简单文件传送协议 | UDP |
| 路由选择协议 | RIP 路由信息协议 | UDP |
| IP地址配置 | DHCP 动态主机配置协议 | UDP |
| 网络管理 | SNMP 简单网络管理协议 | UDP |
| IP电话 | 专用协议 | UDP |
| 流式多媒体通信 | 专用协议 | UDP |
| 多播 | IGMP网际管理协议 | TCP |
| 电子邮件 | SMTP 简单邮件传送协议 | TCP |
| 远端终端接入 | TELNET 远端终端协议 | TCP |
| 万维网 | HTTP 超文本传送协议 | TCP |
| 文件传送 | FTP 文件传送协议 | TCP |
协议端口号（protocol port number）
协议端口号（protocol port number）简称 端口（port）
- 16位的端口号可允许65535个不同的端口号
- 服务器端使用的端口号
- 熟知端口号（well-konwn port number）（系统端口号）
- 登记端口号
- 客户端使用的端口号（短暂端口号）
熟知端口号 0-1023 (www.iana.org) 被分配给TCP/IP最重要的一些应用程序
常用熟知端口号
| 应用 | FTP | TELNET | SMTP | DNS | TFTP | HTTP | SNMP | SNMP(trap) | HTTPS |
|---|---|---|---|---|---|---|---|---|---|
| 端口号 | 21 | 23 | 25 | 53 | 69 | 80 | 161 | 162 | 443 |
登记端口号 1024-49151 使用必须在IANA登记
客户端使用的端口号 49152-65535
UDP
特点：
- 无连接的 发送前无需建立连接
- 尽最大努力交付 主机无需维持复杂的连接状态表
- 面向报文的 对应用层交下来的报文直接发送
- 没有拥塞控制
- 支持一对一、一对多、多对一
- 首部开销小
源端口 发送端的端口 需要对方回信时设置否则为零
长度 UDP数据报的长度 最小值为8字节
校验和 加上伪首部计算
TCP
特点：
- 面向连接的运输层协议 必须先建立连接
- 点对点
- 可靠交付
- 全双工通信
- 面向字节流
TCP的端点 —— 套接字socket
套接字 socket = （IP地址：端口号）
TCP理想的传输条件：
- 传输信道不产生差错
- 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据
停止等待协议
停止等待指的是每发送一个分组就停止等待，等待对方的确认
instance1 无差错情况
发送方只有在确认了接收方的确认报文才会继续发送下一条报文
instance2 出现差错
- 数据报在传输过程中出错了，接收方就丢弃了，然后等待。发送方可以设置一个超时计时器，实现超时重传。
- 发送方在发送数据报时保存发送的副本，只有等到收到确认报文时才会删除副本。
- 对数据报分组进行编号
instance3 确认丢失和确认迟到
- 接收方收到重复的数据报分组就丢弃并发送确认
- 发送方收到迟到的确认数据报就丢弃并发送下一条
- 以上第三点称为自动重传请求ARQ(Automatic Repeat reQuest)
instance4 信道利用率
- 信道利用率=发送分组所需时间 / （发送分组所需时间+RTT+发回确认所需时间）
此处RTT往返时间即数据报从一端到一端的传输时间- 一般情况下发送分组所需时间是小于发送时间的，这样信道利用率较低。需要采用流水传输。
连续ARQ协议
内容
- 发送方维持一个发送窗口，该窗口内的n个分组都可以连续发送出去，无需等待接收方的确认。
- 发送方每收到一个确认，就将发送窗口向前滑动一个分组的位置。
- 接收方采用累计确认的方式，只需返回按序的最后一个分组的确认信息。
TCP报文
- 序号 本报文段所发送数据的第一个字节的序号
(TCP连接中传送的字节流中的每一个字节都按顺序局编号)- 确认号 期待收到对方一个报文段的第一个数据的序号
(若有确认号N,则到N-1为止的所有数据都已经正确收到)- 数据偏移 TCP数据报段的起始位置相对数据报的偏移量
- 保留 置为零
- 紧急URG(URGent) URG=1 表示TCP中含有紧急数据
- 确认ACK(ACKnowledgment) ACK=1 确认号有效
- 推送PSH(PuSH) PUS=1 发送端立马发送一个报文催促接收端立马交付接收应用进程
- 复位SYN(SYNchronization) SYN=1&&ACK=0 表示这是一个请求连接的报文段。若对方同意建立连接则SYN=1&&ACK=1
- 终止FIN(FINis) FIN=1 表示发送端已经发送完毕，要求释放运输连接
- 窗口 发送本报文一方的接收窗口 若窗口值为N,则告诉对方可接收的范围是[ 确认号，确认号+N]
- 紧急指针 指出紧急数据末尾在报文中的位置
- 选项 可变 最大值为40byte
选项：
- 最大报文长度MSS(Maximum Segment Size) TCP报文段数据字段的最大长度，默认值为536byte
设置的原因：
- TCP的首部加上IP的首部至少40byte，若TCP的数据部分很小的话，网络利用率就低了。
- 若TCP报文段非常长，分解和合并就需要很大的开销
- 窗口扩大 扩大窗口的范围
- 时间戳 计算往返时间RTT 发送和确认时记录计算
- 选择确认
超时重传的自适应算法
报文段的往返时间RTT 收到报文确认的时间减去相应报文的发出时间
加权平均往返时间RTTs（平滑的往返时间）
RTTs初始值为RTT，经过每次测量：
新的RTTs = (1-α） x (旧的RTTs）+ α x（新的RTT样本）
- 当α比较小时，RTT值更新较慢
- 当α比较大时，RTT更新较快
- α建议值为0.125
超时重传时间RTO（Retransmission Time-Out）
RTRd初始值为RTT/2
RTO = RTTs + 4 x RTTd
新的RTTd=(1-β） x (旧的RTTd) + β x |RTTs - 新的RTT样本）
β推荐值为0.25
Question：如何判断某确认报文段是对先前发送的报文的确认，还是对后来重传的报文段的确认？
- 若收到的确认报文是对重传报文的确认，但是被源主机当作是对原来报文的确认。此时，RTTs、RTO偏大。后续的报文段再发生相同的事，则RTO会越来越长。
- 同理，相反的会越来越小
Solving： Karn算法
- 计算加权平均RTTs时,只要报文段重传，就不采用其往返时间样本计算。
- 报文每重传一次，就把超时重传时间RTO增大一些。如为原来的两倍。
TCP的流量控制
让发送方的发送速率不要太快，让接收方来得及接受
通过设置窗口来进行流量控制持续计时器
- 设置原因：假设发送方不被接收方允许发送数据(零窗口通知)，此时，接收方告知发送方能够接受数据了（修改窗口大小），告知过程中失败了。发送方在等待接收方的发送通知，而接收方等待发送方发送数据，陷入死循环。
- 何时启动： TCP连接的一方一收到对方的零窗口通知
- 运行：当持续计时器到期，发送一个零窗口的探测报文段（1byte），要求对方再返回一个窗口通知
TCP传输效率的提高
Nagle算法 解决数据报段的等待问题
- 含义：通过减少必须发送包的个数来增加网络软件系统的效率
- 若发送应用进程要把发送的数据逐个字节地送到TCP的发送缓存，则就先发第一个字节的数据，之后的缓存起来统一发送。
- 步骤：
- 应用程序逐字将数据放入TCP发送缓存，将第一个数据字节先发送出去。
- 等到该数据字节确认之后再把发送缓存中的所有数据组装成一个报文发出去，同时对随后的数据进行缓存。
- 只有在收到对前一个报文段的确认后才继续发送下一个报文段。
模糊窗口综合征（silly window syndrome）
- 问题的出现条件：
1.TCP接收方缓存已满
2.应用程序一次只读1比特,然后向发送方发送确认，并把窗口设置为1比特,紧接着发送发发来1字节的数据，接收方确认。如此循环。- 结果：
网络效率低- 解决方案：
1.让接收方等待一段时间
2.等到接受缓存已经有一半空闲的空间。
TCP的拥塞控制
拥塞（congestion）
对网络的某一资源的需求超过了该资源所能提供的可用部分
拥塞控制
防止过多的数据注入到网络中，这样可以使网络中的路由器或者链路不致过载。拥塞控制是一个全局性的过程。
流量控制
点对点通信量的控制
TCP拥塞控制的方法
拥塞控制的算法
- 慢开始（slow-start）
- 拥塞避免（congestion avoidance）
- 快重传（fast retransmit）
- 快恢复（fast revovery）
Question 如何判断是否发生拥塞？
- 出现了超时
- 接收到了3个相同的ACK
执行算法时遇到超时,3-ACK，ssthresh/=2 cwnd=1
ssthresh 慢开始门限
SMSS (Sender Maximum Segment Size)最大报文段
cwnd (congestion window) 拥塞窗口 发送方让自己的发送窗口等于拥塞窗口
慢开始
增加原则：拥塞窗口增加量=min(N,SMSS)
（N为最近一次收到报文的数据量）
特点：每经过一次传播轮次，拥塞窗口cwnd就加倍
停止条件：cwdn > ssthresh
拥塞避免
增加原则：拥塞窗口增加量=1
停止条件：发生拥塞
停止时操作：ssthresh = cwnd/2 cwnd=1
快重传
出现条件：收到连续的3个相同ACK
特点 接收方收到了失序的报文段也要立即发送相应的确认报文（如[M1 M2 M3丢失 M4] 对应的确认报文为 [M1 M2 M2 M2]）此时，发送方一连收到3个重复的确认，立刻进行重传，这样就不会出现超时。
转而执行快恢复。
快恢复
cwnd /= 2 即等于 慢开始门限
转而执行拥塞避免
三次握手
- 客户端打开连接 发送报文请求 (SYN=1,seq=x)
- 服务端收到连接请求 发送确认报文 (SYN=1,ACK=1,seq=y,ack=x+1)
- 客户端收到确认后 发送确认的确认报文 (ACK=1,seq=x+1,ack=y+1)
服务端一直处于监听状态
四次挥手
- 一方发送连接释放报文 (FIN=1,seq=u)
- 另一方收到释放请求 发送确认报文 (ACK=1,seq=v,ack=u+1)
- 另一方 再发送连接释放报文 (FIN=1.ACK=1,seq=w,ack=u+1)
- 一方发回确认报文 (ACK=1,seq=u+1,ack=w+1)
双方都可以主动关闭连接
网友评论