计算机网络
| 所属层 | 设备 | 数据单元 | 网络协议 | 主要头部信息 |
|---|---|---|---|---|
| 物理层 | 中继器和集线器 | 数据位 | 无 | 无 |
| 链路层 | 网卡、网卡和交换机 | 数据帧 | PPP（点对点信道）、CSMA/CD（广播信道）等 | 源MAC地址和源MAC地址，有尾部 |
| 网络层 | 路由器、防火墙、三层交换机 | 数据包 | IP（网际协议）、ARP（地址解析协议）、ICMP（网络控制报文协议）等 | 源IP地址和目标IP地址 |
| 传输层 | 进程和端口 | 数据段 | TCP（传输控制协议）和UDP（用户数据报协议） | 源端口号和目标端口号 |
| 应用层 | 应用程序 | 报文 | HTTP、DNS、FTP、SSH、DHCP等 | APP的首部信息 |
UDP
- 无连接，不可靠协议
- 面向数据报文传输
- 无拥塞控制
TCP
- 两端点到点、全双工通信
- 面向连接，可靠的协议
- 面向字节流传输
- 有拥塞控制和流量控制，使用滑动窗口实现
建立连接
三次握手的原因
客户端和服务端都要知道的四个信息，自己和对方的发送、接收功能是否正常，即两张表相同的表拥有这四个字段，在都确认无误后就是建立连接
- 客户端：我要建立连接
- 服务端：确认收到建立连接请求，我也要建立连接
- 客户端：确认收到建立连接请求
- 开始数据传输
避免失效的请求建立连接引发的错误，即若是两次握手则会导致客户端第一次请求连接时由于网络延时导致重新请求连接，第二次连接请求比第一次连接请求先到达导致的错误和资源浪费
释放连接
四次挥手的原因
- 客户端：我要释放连接，不再发送数据
- 服务端：确认收到释放连接请求，继续传送数据
- 服务端：我也要释放连接，不再发送数据，确认收到你的连接请求
- 客户端：确认收到释放连接请求
服务端收到释放连接请求时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送释放连接请求给对方，因此确认和释放连接请求会分开为两次，从而导致多了一次
客户端最后还要等待2MSL的原因
由于最后一个报文没有确认消息，为了保证客户端发送服务端确认释放连接的请求能到达服务端，若在这个时间段内服务端未能收到确认释放连接请求，则会重新发送一次释放连接请求
确保当前连接所有报文都已经过期，由于最后一个报文都过了2MSL，所以全部的报文都已经过期了
Comments NOTHING