目录
- 汇总
- 移动蜂窝网络
- 公司内网组成
- 移动网络
- 家用网络
- 整体关系
- tcp三次握手,四次挥手
- 连接和会话区别
- 双工/单工
- 三次握手
- 四次挥手
- tcp粘包拆包
- TCP 的拆包和粘包
- TCP段
- Sequence Number 和 Achnowledgment Number
- MSS
- tcp滑动窗口,流速控制
- 重传
- 快速重传
- 流速控制
- tcp和udp协议
汇总
移动蜂窝网络
公司内网组成
- 公司网络从本地网络服务提供商ISP接入,然后内部再分成一个个子网
- 路由器和链路层交换机具有交换能力,这个能力是: 比如要传递一首几MB的歌曲,歌曲本身不是一次传输完成的,而是被拆分成很多个封包。每个封包只有歌曲中的一部分数据,而封包一旦遇到岔路口多个路由器或者交换机,就需要封包交换技术帮助每个封包选择最合理的路径
- 两个网络可以通过路由器进行连接,多台设备可以通过交换机进行连接。但是路由器通常也具有交换机的功能
-
本地网络提供商ISP提供的互联网先到达边缘的路由器,然后再渗透到内部的网络节点。公司内部的若干服务器可以通过交换机形成一个局域网络;公司内部的办公设备,比如电脑和笔记本,也可以通过无线路由器或者交换机形成局域网络。局域网络之间,可以通过路由器、交换机进行连接,从而构成一个更大的局域网
公司内网组成.png
移动网络
-
在移动网络的设计中,通信的核心被称作蜂窝塔,有时候也称作基站。六边形的设计能够很好无死角覆盖所有的角落,其他形状没有六边形合适
移动网络.png
- 对于最小蜂窝网络来说,大概这样,ISP将网络供给处于蜂窝网络边缘的路由器,路由器连接蜂窝塔,再通过蜂窝塔/基站提供给处于六边形地区中的设备
-
随着移动网络的发展,一个蜂窝网格中的设备越来越多,也出现了基站覆盖有重叠关系的网格,这样设计的好处是,当一个基站过载、出现故障,或者用户设备周边信号出现不稳定,就可以切换到另一个基站的网络,另一方面,在一定范围内的区域,离用户较近的地方还可以部署服务器,帮助用户完成计算。这相当于计算资源的下沉,称为边缘计算
最小蜂窝网络.png
家用网络
- 家用联网设备越来越多。比如说冰箱、空调、扫地机器人、灯光、电动窗帘
- 一方面家用网络会通过路由器接入本地 ISP 提供的网络服务。另一方面,一些设备,比如电脑、笔记本、手机、冰箱等都可以直接和路由器连接
-
还有一些家用设备,比如说 10 多块钱的灯泡,不太适合内部再嵌入一个几十块钱可以接收 WI-FI 的芯片,这个时候就可以考虑用蓝牙控制电灯。路由器提供蓝牙不现实,因此一些家用电器也承担了蓝牙设备的控制器,比如说智能音箱。这样的设计,即便网络断开,仍然可以控制这些家用设备
家用网络.png
整体关系
- 网络基础设施往往不能一次性传输太大的数据量,因此通常会将数据分片传输。比如传输一个 MP3,我们会将 MP3 内容切分成很多个组,每个组也称作一个封包,英文都是 Packet。这样,如果一个封包损坏,只需要重发损坏的封包,而不需要重发所有数据
-
网络中两点间的路径非常多,如果一条路径阻塞了,部分封包可以考虑走其他路径
整体关系.png
tcp三次握手,四次挥手
- TCP(Transport Control Protocol)是一个传输层协议,提供 Host-To-Host 数据的可靠传输,支持全双工,是一个连接导向的协议。TCP 提供的是 Host-To-Host 传输,一台主机通过 TCP 发送数据给另一台主机
- TCP需要知道端口号,根据端口号区分应用
连接和会话区别
- 连接是数据传输双方的契约,让两个在通信的程序之间产生一个默契,保证两个程序都在线,而且尽快地响应对方的请求
- 会话是应用的行为,比如微信里张三和你聊天,那么张三和你建立一个会话。你要和张三聊天,你们创建一个聊天窗口,这个就是会话。你开始 Typing,开始传输数据,你和微信服务器间建立一个连接。如果你们聊一段时间,各自休息了,约定先不要关微信,1 个小时后再回来。那么连接会断开,因为聊天窗口没关,所以会话还在。在有些系统设计中,会话会自动重连,或者帮助创建连接
- 会话是应用层的概念,连接是传输层的概念
双工/单工
- TCP 是一个双工协议,数据任何时候都可以双向传输。在任何一个时刻,如果数据只能单向发送,就是单工,所以单工需要至少一条线路。如果在某个时刻数据可以向一个方向传输,也可以向另一个方向反方向传输,而且交替进行,叫作半双工;半双工需要至少 1 条线路。最后,如果任何时刻数据都可以双向收发,这就是全双工
三次握手
- 流程,其中步骤 3 和步骤 4,因为是同时发生的,可以合并成一个 SYN-ACK 响应,作为一条数据传递给客户端,如果只有两次握手,服务端无法确定客户端是否收到ack了
- 客户端发消息给服务端(SYN)
- 服务端准备好进行连接
- 服务端针对客户端的 SYN 给一个 ACK
- 服务端发送一个 SYN 给客户端
- 客户端准备就绪
- 客户端给服务端发送一个 ACK

-
WireShark抓包截图,对应三次握手流程
WireShark抓包截图,对应三次握手流程.png
四次挥手
- 流程
- 客户端要求断开连接,发送一个断开的请求,这个叫作(FIN)
- 服务端收到请求,然后给客户端一个 ACK,作为 FIN 的响应
- 客户端收到服务端的 FIN,同时客户端也可能有自己的事情需要处理完,比如客户端有发送给服务端没有收到 ACK 的请求,客户端自己处理完成后,再给服务端发送一个 ACK
- 服务端流程类似,这里不能马上Fin,因为服务端也可能有数据要处理,有资源要释放

-
WireShark抓包截图,对应四次挥手流程
WireShark抓包截图,对应四次挥手流程.png
tcp粘包拆包
TCP 的拆包和粘包
-
传输层TCP协议发送方会将数据拆分成很多个部分,然后再逐个发送,在目的地,TCP 协议又需要逐个接收数据,对于应用层来说是一次性传完的
拆包.png
- 拆包,也叫TCP段segment原因:
- 稳定性,一次发送的数据越多,出错的概率越大
- 效率,网络中有时候存在着并行的路径,拆分数据包就能更好地利用这些并行的路径
- 发送和接收数据的时候,都存在着缓冲区,大量的应用频繁地通过网卡收发数据,这个时候,网卡只能一个一个处理应用的请求。当网卡忙不过来的时候,数据就需要排队,也就是将数据放入缓冲区
-
操作系统页page有大小限制,太大容易发生页面置换
存在着缓冲区.png
- 粘包: 发往一个目的地的多个数据太小了,为了防止多次发送占用资源,TCP 协议有可能将它们合并成一个 TCP 段发送,在目的地再还原成多个数据
TCP段
-
综述
TCP段.png
- Source Port/Destination Port 描述的是发送端口号和目标端口号
- Sequence Number 和 Achnowledgment Number 是保证可靠性的两个关键
- Data Offset 是一个偏移量。这个量存在的原因是 TCP Header 部分的长度是可变的,因此需要一个数值来描述数据从哪个字节开始
- Reserved 是很多协议设计会保留的一个区域
- URG/ACK/PSH/RST/SYN/FIN 是几个标志位,用于描述 TCP 段的行为
5.1 URG 代表这是一个紧急数据,比如远程操作的时候,用户按下了 Ctrl+C,要求终止程序
5.2 ACK 代表响应, SYN 同步请求,也就是申请握手,FIN 终止请求,也就是挥手, PSH 代表数据推送,也就是在传输数据的意思
Sequence Number 和 Achnowledgment Number
- 这两者确定了应答顺序,是保障顺序的关键
-
截图省了握手过程,192.168向52.1发送http请求,观察Sequence Number 和 Achnowledgment Number
序列号演示.png
-
192.168向52.1发送http请求数据,即序列号演示.png中第一行, 刚开始seq到1了,然后TCP段长度是353,所以下一个seq号是1 + 353 = 354, 这样能够很好的标识发送方生成的seq,接收方也能够更好的识别
image.png
- 52.1回复192.168一个ACK和ACK,PUSH,即序列号演示.png中第二行第三行,这里seq =1, ack = 354,ack 354就标识52.1回复的是192.168第一行http那个请求
-
在看序列号演示.png中第四行,52.1回复192.168,这里seq = 231, TCP段长度是551,所以下个序列是231 + 551 = 782
序列号演示.png中第四行详细.png
- 看序列号演示.png中第五行,是192.168回复52.1,这时候seq = 354, ack=782,seq=354呼应了看序列号演示.png中第一行,下个序列是354,ack = 782标识回复的是 在看序列号演示.png中第四行
MSS
- Maximun Segment Size,TCP 段的大小MSS涉及发送、接收缓冲区的大小设置,双方实际发送接收封包的大小,对拆包和粘包的过程有指导作用,因此需要双方去协商
- 假如TCP 协议不肯拆包,IP 协议就需要拆出大量的包。那么 IP 协议为什么需要拆包呢?这是因为在网络中,每次能够传输的数据不可能太大,这受限于具体的网络传输设备,也就是物理特性。但是 IP 协议,拆分太多的封包并没有意义。因为可能会导致属于同个 TCP 段的封包被不同的网络路线传输,这会加大延迟。同时,拆包,还需要消耗硬件和计算资源
TCP滑动窗口,流速控制
- TCP传输需要保证可靠性,还需要控制流速,这两个核心能力均由滑动窗口提供, 发送方和接受方都有滑动窗口
-
TCP 请求/响应模型, 吞吐量低版本
TCP 请求/响应模型, 吞吐量低版本.png
-
让发送方有请求就发送出去,而不是等待响应。通过这样的处理方式,发送的数据连在了一起,响应的数据也连在了一起,吞吐量就提升了
吞吐量高版本.png
-
如果可以同时发送的数据真的非常多,比如成百上千个 TCP 段都需要发送,这个时候带宽可能会不足,这时候滑动窗口解决排队问题,一个滑动窗口,可以用数组表示,标识了已接受,未发生,正在处理,失败了只需要重复本滑动窗口的数据。浅绿色代表发送了,但是没有收到 ACK 的段,白色代表没有发送的段,深绿色代表已经收到 ACK 的段
滑动窗口.png
- 有两个封包的 ACK 到达,因此标记为绿色,滑动窗口右移

- Source Port 是源端口号。因为 UDP 协议的特性(不需要 ACK),因此这个字段是可以省略的。但有时候对于防火墙、代理来说,Source Port 有很重要的意义,它们需要用这个字段行过滤和路由
- Destination Port 是目标端口号(这个字段不可以省略)
- Length 是消息体长度。Checksum 是校验和,作用是检查封包是否出错。Data octets 就是一个字节一个字节的数据
UDP 与 TCP的区别
- 目的差异,首先,这两个协议的目的不同:TCP 协议的核心目标是提供可靠的网络传输,而 UDP 的目标是在提供报文交换能力基础上尽可能地简化协议轻装上
- 可靠性差异,TCP 核心是要在保证可靠性提供更好的服务。TCP 会有握手的过程,需要建立连接,保证双方同时在线。而且TCP 有时间窗口持续收集无序的数据,直到这一批数据都可以合理地排序组成连续的结果。UDP 并不具备以上这些特性,它只管发送数据封包,而且 UDP 不需要 ACK,这意味着消息发送出去成功与否 UDP 是不管的
- 连接 vs 无连接,TCP 是一个面向连接的协议,传输数据必须先建立连接。 UDP 是一个无连接协议
- 流控技术,TCP 使用了流控技术来确保发送方不会因为一次发送过多的数据包而使接收方不堪重负,UDP没有这样
- 传输速度,UDP 协议简化,封包小,没有连接、可靠性检查等,因此单纯从传输速度上讲,UDP 更快
使用场景
- TCP 每个数据封包都需要确认,因此天然不适应高速数据传输场景,比如观看视频(流媒体应用)、网络游戏(TCP 有延迟)等。具体来说,如果网络游戏用 TCP,每个封包都需要确认,可能会造成一定的延迟;再比如音、视频传输天生就允许一定的丢包率
- Ping 和 DNSLookup,这类型的操作只需要一次简单的请求/返回,不需要建立连接,用 UDP 就足够了
- TCP 场景, 远程控制(SSH),File Transfer Protocol(FTP),邮件(SMTP、IMAP),点对点文件传出微信等
- UDP 场景,网络游戏,音视频传输,DNS,Ping,直播
- 模糊地带,HTTP(目前以 TCP 为主),文件传输
参考文章
- 拉钩教育之计算机网络通关 29 讲
网友评论