| 协议 | 体现 | 名字 |
|---|---|---|
| 应用层 | FTP | |
| 传输层 | TCP | 段 |
| 网络层 | IP | 数据报 |
| 链路层 | 以太网 | 帧 |
- 帧 --> IP / ARP / RARP
- IP --> TCP / UDP / ICMP / IGMP
- TCP/UDP --> 应用程序
- IP/ARP/RARP 以太网封装成帧, 但是IP属于网络层, 其他属于链路层
- TCP/UDP/ICMP/IGMP IP协议封装成数据报, 但是TCP/UDP属于传输层, 其他属于网络层
| 目的地址(mac) | 源地址(mac) | 类型 | 数据 | CRC校验 |
|---|---|---|---|---|
| 6 | 6 | 2 | 46-1500 | 4 |
| IP(0800) | IP数据报 | |||
| ARP(0806) | ARP请求(28)+PAD(18) | |||
| RARP(8035) | RARP请求(28)+PAD(18) | |||
| 以太网头部开始 | 数据开始 |
因为通讯只知道 IP+端口, 不知道mac地址, ARP就起到这个作用
| 目的地址 | 源地址 | 帧类型 | 硬件类型 | 协议类型 | 硬件地址长度 | 协议地址长度 | op | 发送端以太网地址 | 发送端ip地址 | 目的以太网地址 | 目的IP地址 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 6 | 6 | 2 | 2 | 2 | 1 | 1 | 2 | 6 | 4 | 6 | 4 |
| 以太网头部开始 | 此开始是arp请求/应答,28个字节 | ||||||||||
| 08006是ARP | 1为以太网 | 08000是IP | 1是arp请求,2是应答 |
地址在头部和arp请求各出现了一次, 因为链路层有可能不是以太网
| 版本 | 首部长度 | 服务类型 | 总长度 | 标识 | 标志 | 片偏移 | ttl | 协议 | 首部检验和 | 源ip | 目的ip | 选项 | 数据 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 4 | 4 | 8 | 16 | 16 | 3 | 13 | 8 | 8 | 16 | 32 | 32 | 如果有 | |
| IPv4,是4 | 最小延迟,最大可靠性.. | 整个数据报字节数 | 分片和重新组装 | 分片 | 分片 | 过一个路由器-1 | tcp/udp | 只校验IP首部 |
- 首部长度和数据长度都会变的,
- 首部长度是4的倍数, 最小是20个字节, 不带任何选项, 最大是60个字节
32位地址划分网络号和主机号, 网络号相同是同一网段,直接通信, 不同需要路由器转发
| A类 | B类 | C类 | D类 | E类 |
|---|---|---|---|---|
| 7位网络号,24主机号 | 14网络号,16主机号 | 21网络号,8主机号 | ||
| 地址数量最大(同网段主机数) | 65536 | 255 | 多播 | 未用 |
| 0.0.0.0,127.255.255.255 | 128.0.0.0,191.255.255.255 | 192.0.0.0,223.255.255.255 | 224.0.0.0,239.255.255.255 | 240.0.0.0,247.255.255.255 |
- B类申请完, A类浪费
- 新的划分方案, CIDR, 和IP地址数值无关,需要额外的子网掩码表示, ip地址与子网掩码与运算得到网络号, 主机号,全0到全1是子网的地址范围
- 私有地址,不能出现网络
- 10.*
- 172.16. 到 172.31
- 192.68.*
- 127.* 用于本地环回测试
- 255.255.255.255 表示网络内部广播
- 主机号全为0只表示网络不表示主机, 当然了需要和子网掩码配合 192.168.10.0
- 主机号全为1,表示广播网络所有主机, 192.168.10.255 广播到 192.168.10.0网络
| 源端口 | 目的端口 | UDP长度 | UDP校验和 | 数据(如果有) |
|---|---|---|---|---|
| 16 | 16 | 16 | 16 |
- http tcp 80
- ftp tcp 21
- tftp udp 69
udp特点
- 没有发送成功,也不提醒应用层, 只是封装成段交给IP协议层
- 多个数据包顺序不保证
- 发送过快,可能丢失数据
| 源端口 | 目的端口 | 序号 | 确认序号 | 首部长度 | 保留 | URG | ACK | PSH | RST | SYN | FIN | 窗口大小 | 检验和 | 紧急指针 | 选项 | 数据 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 16 | 16 | 32 | 32 | 4 | 6 | 1 | 1 | 1 | 1 | 1 | 1 | 16 | 16 | 16 |
- 首部长度和IP类似,4字节为单位, 最大60字节
- 没有选项字段,最短20个字节
- 客户端 SYN 1000(0) mess 1460
SYN表示连接请求,序号1000是为了让服务器+1, SYN和FIN也要占一个序号, 如果用这两个下次也+1 mess表示最大段尺寸,如果超过链路层帧长度,需要IP层分片,所以建议服务器不要超了这个长度
- 服务器 SYN 8000(0) ACK 1001 mess 1024
我收到了,并且+1, 我的序号是8000, 尺寸是1024
- 客户端 ACK 8001
我也收到了
- 服务器的应答和请求在一个段中发出,所以有3个段, 所以三次握手
- 如果没有这个端口,一方会向另一方发送RST位
- 客户端 1001(20), ACK 8001
发了20个字节
- 服务器 8001(10), ACK 1021
收到,下次你可以发1021开始的, 我也给你回10个字节
- 客户端 ACK 8011
收到, 下次你发8011开始的
- 如果没收到ACK, 超时重发, 收到了才会释放缓存
- tcp其实支持互发, 就是全双工
- 客户端 FIN 1021(0) ACK 8011
FIN表示关闭连接
- 服务器 ACK 1022
OK,收到
- 服务器 FIN 8011(0), ACK 1022
那我也关闭, 给发个FIN
- 客户端 ACK 8012
好, 我也同意
- 关闭需要4次握手, 为什么不合并? 因为存在连接半关闭的情况??
滑动窗口解决缓冲区满的问题
-
客户端 SYN win 4096 我的缓冲还有4K字节
-
服务器 SYN ACK win 6144 我的缓冲是6K字节
-
客户端 疯狂发数据, 到6K不发了
-
服务器 接了2K, win2048, 表示我还有2K空闲
-
客服端 发数据 发数据, 发数据, FIN
-
服务器 ACK ACK ACK
-
服务器 FIN, 此处多次交流, 所以服务器的FIN不和应答客户端FIN合并
-
客服端 ACK
- tcp 客户端一次1K的发,服务器可以一次2K的接,也可以几个字节接, 所以tcp是面向流的
- udp 面向消息, 一次一个消息, 只能以消息为单位