搞懂OSI七层模型及TCP三次握手、四次挥手

---

要点归纳

• 基本概念
  • 比特 bit、字节 Byte、速率、带宽、吞吐量、时延、时延带宽面积、往返时间、利用率、丢包率
• OSI七层模型
  • 物理层、数据链路层、网络层、传输层、会话层、表示层、应用层
• OSI网络标准模型
  • 物理层、数据链路层、网络层(网际层)、传输层、应用层
• OSI各层之间交互过程、传输数据格式
• TCP、UDP
  • TCP、UDP区别
  • TCP三次握手、四次挥手

---

基本概念

比特 bit

binary digit(二进制数字) 计算机中数据存储的最小单位1比特 也叫做 1位每个 0 或 1 就代表一位
[ cpu位数 指的是 cpu一次所能处理的最大位数 ]

字节 Byte

Byte 也称为 B 一个字节等于八位 即 ： 1B = 8b 是计算机中存储数据量的基本单位

 1B = 8b
1KB = 1024B = 2^10 B 
1MB = 1024KB = 2^20 B
1GB = 1024MB = 2^30 B
1TB = 1024GB = 2^40 B
... ...

速率

单位时间内，计算机能够传输的数据量(比特)。也称为比特率、数据率

带宽

单位时间内，从网络中的某一点到另一点所能通过的最高数据率

吞吐量

单位时间内，通过某个网络的数据量

时延

数据从网络的一端到另一端所花费的时间。由 发送时延、传播时延、处理时延、排队时延

• 发送时延：源主机将数据分组发往传输线路上花费的时间分组长度(b)/发送速率(b/s)
• 传播时延：数据在一定长度的链路上传播时所花费的时间信道长度(m)/电磁波传送速度(m/s)
• 处理时延：数据在交换节点进行存储转发花费的时间
• 排队时延：数据在进入路由器后，排队等待处理的时间

时延带宽面积

可理解为，发送端发送的第一个比特即将到达终点时，发送端已经发出了多少个比特

往返时间

从发送方开始发送数据开始，到发送方收到接收方确认消息时，所花费的时间。

利用率

用来表示某信道中有半分之几的时间是被利用的

• 根据排队理论，某信道利用率增大时其产生的时延也越多

丢包率

在一定的时间内传输过程中丢失的分组数量与总分组数量的比率接口丢包率、结点丢包率、链路丢包率、网络丢包率等

• 分组在传输过程中出现误码，被节点丢弃
• 网络堵塞：分组到达了一台队列已满的交换机时，被丢弃

MAC地址

以太网的MAC自层所用的地址 【数据链路层】

IP地址

TCP/IP体系结构：网络层使用的地址 【网络层】

ARP协议

TCP/IP体系结构：通过IP地址获取到MAC地址 – 【网络层】

---

OSI模型 - 七层 （国际标准）

• 物理层
• 数据链路层
• 网络层
• 传输层
• 会话层
• 表示层
• 应用层

物理层

解决连接在计算机上的各种不同媒体中使用何种信号来代表比特0、1传输的问题

• 导引型传输媒体：例如同轴电缆、双绞线、光纤、集线器 非导引型传输媒体：微波通信(2~40GHZ) 例如：2.4GHZ和5.8GHZ频段的Wifi

数据链路层

解决分组在一个网络或一段链路上传输的问题

• 给上层交付的数据单元添加帧头及帧尾，用于找到目的主机 MAC地址等信息 [PPP协议]

网络层

实现网络互联，解决数据包在多个网络间传输(路由)问题

• 多个网络间的通信。包括：路由器

传输层

为应用进程之间基于网络的通信问题提供服务

• TCP/IP协议：使用端口号区分不同应用进程
  • 发送方发送带有协议字段的TCP或UDP接收方通过协议字段选择上交TCP或UDP协议代码：TCP : 6 UDP : 17
  • TCP 协议 ：SMTP(25) FTP(20/21) BGP(179) HTTP(80) HTTPS(443)
  • UDP 协议 ：DNS(53) RIP(520) TFTP(69)SNMP(161) DHCP(67/68)

会话层

解决进程之间进行会话的问题

表示层

解决通信双方通信信息的表示问题

应用层

解决通过应用进程之间的交互来实现特定网络应用的问题

• 包括：字符集转化、数据加解密、文本压缩、数据格式转换

---

OSI模型 -（网络标准）

物理层

传输 比特流 001101010100101…

数据链路层

传输 数据帧 数据链路层上传输的数据包

网络层

传输 网络数据报/分组 IP

传输层

传输 TCP报文段/UDP用户数据段 TCP \ UDP

应用层

传输 数据报文 HTTP \ SMTP \ FTP \ RTP …

---

各层之间 数据传输封装过程

---

TCP、UDP区别

	UDP	TCP
可靠性	无连接-不可靠的	有连接-可靠的
传播方式	单播、多播、广播	单播
传播类型	【面向应用报文】	【面向字节流】
传播过程	直接将应用报文添加UDP首部进行传输	【发送方】将字节流编号存储在发送缓存中，根据发送策略提取字节，构建TCP报文段进行发送 【接收方】从报文段中取出数据，并存存储在接收缓存中，将缓存中的字节交付给上级应用进程
传播方式	单播、多播、广播	单播
保障机制	路由器或接收方识别到传输数据误码，则仅仅将数据丢弃	通过建立连接进行可靠传输流量控制(滑动窗口)、超时重传、拥塞控制等
应用场景	适用于：实时服务电话、语音、视频	适用于：要求可靠性的传输文件传输、数据传输等

---

TCP 三次握手

建立连接

TCP 四次挥手

释放连接

---

为什么建立连接要 三次握手？两次不行？

三次握手 为了 保证建立一个 安全可靠的 连接

第一次为 客户端 向 服务器 发送建立连接请求，
第二次为 服务器 向 客户端 响应建立连接请求，
第三次为 客户端 向 服务器 响应收到 服务器的确响应
---此时连接 建立成功

假如 修改为两次过程，第二次 服务端直接建立连接：
①：那么 服务端就无法知道 自己的同意建立连接请求 客户端是否正确收到，
如果客户端未收到，那么客户端将不会建立与服务端的连接，那么服务端将建立了一个单向的请求。连接不可靠。
②：并且如果客户端迟迟 未收到 服务端的响应，则会进行重传建立连接请求，服务端可能建立多个无效连接

---总的来说，两次请求，只能是客户端知道了 我发送的请求 服务端能正确收到，
   但是服务端 无法知道 我发的请求，客户端能否正确收到

为什么关闭连接要 四次挥手？三次不行？

第一次为 客户端 向 服务端 发送断开连接请求，
第二次为 服务端 向 客户端 响应收到断开连接请求，
第三次为 服务端 向 客户端 发送断开连接请求，
第四次为 客户端 向 服务端 响应收到并确认断开连接请求。

那么为什么，服务端在第二次响应客户端断开连接请求的时候，不直接把连接释放掉，而再进行第三次、第四次挥手？

因为，第一次挥手 为 客户端 主动发起 请求断开连接，此时服务端有可能还有业务数据要发给 客户端，所以不能直接断开，
只是向客户端响应下，同意断开。

当服务端 处理完请求后 会 再主动向 客户端 发送 断开连接 请求，并等待 客户端 响应确认 该请求后 最终断开 服务端 连接。

TCP挥手时的time-wait状态为什么需要持续2MSL？

MSL：报文最大生存时间

TCP 服务端 向 客户端发起释放连接请求，在得到响应前会等待 2MSL 时间，如果超过这个时间为收到客户端响应，则会重传
	等待 2MSL 时长原因是，服务端发送请求到客户端，最大时间是 1MSL，客户端响应确认请求最大时间是 1MSL，
	故认定超过这个时间 认为请求丢失了，会进行重传
	  
TCP 客户端向服务器响应后，会等待2MSL时间，超过这个时间，则认为服务端收到了我的响应
	等待 2MSL 时长原因是 ，客户端响应 到 服务端 最大时间为 1MSL 如果假设 服务端没收到 则会发起重传
	再 等待 1MSL 时间 如果 没收到 服务端 再次确认 则认为 服务端 正常收到了 确认响应

以上内容，若有不足或错误，还望指正。欢迎探讨 ~

不止于前 未来可期 ···

---