计算机网络思维导图模板_ProcessOn思维导图、流程图

TCP

三次握手

挥手

拥塞算法

SSL

IP

输入URL

解析 URL
生产 HTTP 请求信息
DNS解析
TCP连接
发送HTTP请求
服务器处理请求并返回HTTP报文
浏览器解析渲染HTML页面
连接结束

- 第一步工作是解析 URL

生产 HTTP 请求信息

DNS解析：查询服务器域名对应的 **IP** 地址

- 本地 DNS 服务器：缓存里的表格
- 否则：根域名服务器，不直接用于域名解析，但能指明一条道路。

应用程序(浏览器)通过调用 Socket库委托协议族工作

TCP连接：负责**收发数据**的 TCP 和 UDP 协议，接受**应用层的委托执行收发数据的操作**。

IP 协议控制网络包收发操作：将网络包发送给对方的操作就是由 IP 负责的。

ICMP

传送过程中产生的错误以及各种控制信息。

ARP

IP 地址查询相应的以太网 MAC 地址。

网卡

数字信息转换为电信号

靠网卡驱动程序。

有Mac地址

交换机

交换机的端口不具有 MAC 地址

MAC 地址表缓存数据包

交换机根据 MAC 地址表查找 MAC 地址，然后将信号发送到相应的端口。

数据包通过交换机转发抵达了路由器，离开子网

路由器

路由器是基于 IP 设计的，俗称三层网络设备，路由器的各个端口都具有 MAC 地址和 IP 地址;

1. 输入url后：解析Url
2. DNS解析：首先需要找到这个url域名的服务器ip,为了寻找这个ip，浏览器首先会寻找缓存，查看缓存中是否有记录，缓存的查找记录为：浏览器缓存-》系统缓存-》路由器缓存，缓存中没有则查找系统的hosts文件中是否有记录，如果没有则查询DNS服务器，
3. 构造Http请求：得到服务器的ip地址后，浏览器根据这个ip以及相应的端口号，构造一个http请求，这个请求报文会包括这次请求的信息，主要是请求方法，请求说明和请求附带的数据，
4. TCP连接：并将这个http请求封装在一个tcp包中，这个tcp包会依次经过传输层，网络层，数据链路层，物理层到达服务器，服务器解析这个请求来作出响应。
5. 响应返回html：服务器解析这个请求来作出响应，返回相应的html给浏览器，因为html是一个树形结构，浏览器根据这个html来构建DOM树，在dom树的构建过程中如果遇到JS脚本和外部JS连接，则会停止构建DOM树来执行和下载相应的代码，这会造成阻塞，这就是为什么推荐JS代码应该放在html代码的后面
5. 之后是渲染页面，因为html文件中会含有图片，视频，音频等资源，在解析DOM的过程中，遇到这些都会进行并行下载，浏览器对每个域的并行下载数量有一定的限制，一般是4-6个，当然在这些所有的请求中我们还需要关注的就是缓存，缓存一般通过Cache-Control、Last-Modify、Expires等首部字段控制。

socket编程

Linux内核中会维护两个队列:

未完成连接队列(SYN 队列)

接收到一个 SYN 建立连接请求，
处于 SYN_RCVD 状态;

已完成连接队列(Accpet 队列)

已完成 TCP 三次握手过程，
处于 ESTABLISHED 状态;

客户端 connect 成功返回是在第二次握手
，服务端 accept 成功返回是在三次握手成功之后。

抓包工具

tcpdump

仅支持命令行格式使用

Wireshark

可视化分析网络包的图形页面。

curl

http://www.ruanyifeng.com/blog/2019/09/curl-reference.html

不带有任何参数时，curl 就是发出 GET 请求。

相关网络过程

二维码扫描登录

https://blog.csdn.net/ALakers/article/details/108445538

https://www.cnblogs.com/jamaler/

首次登录

二维码其实是字符串的图片表现形式

基于token的认证机制
1、首次登录：客户端向服务器传送【用户信息+密码+设备信息】进行认证;
2、服务端认证通过后,通过相关算法(hash)生成【token与设备信息进行对应】,存储在服务端并将token回传到客户端;
3、客户端每次访问API时,需要携带【token+设备信息】作为验证信息;【服务端进行解码认证】
4、服务端【验证token+设备信息】是否对应,验证通过后,返回API响应,验证不通过,拒绝服务;
特别注意:token是某个客户端私有的,即使有token,没有对应的设备信息,也是验证不通过的

验证二维码

二维码登录原理主要基于token的认证机制+二维码状态变化实现
1、二维码状态有三种:待扫描、已扫描待确认、已确认;
2、待扫描:PC端携带设备信息向服务端发送请求,服务端生成二维码ID与设备信息进行绑定,将二维码ID返回给PC端,PC端已二维码的形式显示二维码;
3、PC端通过轮询的方式向服务端查询二维码的状态是否发生变化;
4、移动端扫描PC端二维码,获取到二维码ID,移动端带二维码ID+移动端身份信息(token)发送给服务端,服务端验证身份信息通过后,将二维码ID与身份信息绑定,并生成临时token返回给移动端,二维码状态变为已扫描待确认;
5、移动端确认登录,并携带临时token请求服务端,服务端验证临时token通过后,
改变二维码状态为已确认并生成PC-token,PC端通过轮询知二维码状态为已确状态

token，cookies，session

https://www.cnblogs.com/moyand/p/9047978.html

为什么token安全

https://muyiy.cn/question/browser/28.html

CSRF：跨站请求攻击

cookie：用户点击了链接，cookie未失效，导致发起请求后，
浏览器自动携带cookie，后端以为是用户正常操作，于是进行扣款操作。

token：由于浏览器不会自动带上token
需要开发者手动将token放在header中带过去

5层协议

应用层

直接为用户的应用进程提供服务

报文

HTTP,SMTP,FTP,DNS,TELNET(远程登录)，RPC

远程过程调用

DNS

域名系统

将域名与IP映射到一个分布式数据库：方便访问

表示层

包括数据压缩、数据加密、数据描述

数据描述：解决计算机内部存储格式问题

会话层

提供数据交换的定界与同步功能

建立检查点与恢复方案

传输层

负责向两个主机中进程（端口）之间的通信提供服务

复用

多个进程使用一个IO资源发送消息时：去往下层

分用

多个进程使用一个IO资源接收消息：去往上层

TCP

面向连接的、可靠的协议

文件传输，邮件传输

传输形式：字节流

首部字节：20-60

特点

数据传递时：有确认、窗口、重传、拥塞控制机制

数据传完后：还会断开连接用来节约系统资源

增加了许多开销，首部增大

UDP

无连接的，仅最大力（不可靠）

QQ视频，DNS

C：不需要先建立连接
S：不需要给出任何确认

传输形式：数据报文段

首部字节：8

传输效率快

多对多

网络层

将数据报从源主机移动到目的主机，需要为数据报选择路径
选择合适的网间路由与交换节点，确保数据快速到达

IP

IP数据报

Internet Protocol

20字节

ICMP

封装为分组

路由器

数据链路层

负责将帧从一个节点移动到下一节点

数据报->帧

以太网

WiFi

控制信息

差错控制

ARP：地址解析协议

将IP解析成Mac地址

物理层

传递从数据链路层接收的位并把这些位（byte）转化为电磁信号，
然后再转交给传输介质

byte-比特

HTTP

超文本传输协议

图片，视频，HTML->超链接

HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。

状态码

301是永久重定向，而302是临时重定向。

301比较常用的场景是使用域名跳转。
302用来做临时跳转比如未登陆的用户访问用户中心重定向到登录页面。

常见字段

Connection

Keep-Alive

客户端要求服务器使用 TCP 持久连接

HTTP长连接,短连接

1.0中默认使用短连接。客户端和服务器每进行一次HTTP操作，建立一次连接，任务结束就中断连接

1.1起，默认使用长连接，用以保持连接特性
传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接

请求头

Host 字段

用来指定服务器的域名--www.A.com

Accept

接受哪些数据格式。

响应头

Content-Length

服务器在返回数据时，表明本次回应的数据长度。

Content-Type

服务器回应时，告诉客户端本次数据是什么格式。

GET/POST

GET

从服务器获取资源

静态的文本、页面、图片视频

1. 浏览器在回退时，get 不会重新请求，但是post会重新请求。【重要】
2. get请求会被浏览器主动缓存，而post不会。【重要】
3. get请求的参数，会报保留在浏览器的历史记录里，而post不会。做业务时要注意。为了防止CSRF攻击，很多公司把get统一改成了post。
4. get请求在url中传递的参数有大小限制，基本是2kb`，不同的浏览器略有不同。而post没有注意。
5. get的参数是直接暴露在url上的，相对不安全。而post是放在请求体中的。

https://www.cnblogs.com/logsharing/p/8448446.html

请求参数包含在URL中

不安全

发送数据小

浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；

POST

向 URI 指定的资源提交数据

数据就放在报文的 body 里

token:header->Authorization

POST产生两个TCP数据

浏览器先发送header，服务器响应100 continue，
浏览器再发送data，服务器响应200 ok（返回数据）。

与浏览器有关

安全和幂等

安全」是指请求方法不会「破坏」服务器上的资源。

幂等」，意思是多次执行相同的操作，结果都是「相同」的。

GET 方法就是安全且幂等的，因为它是「只读」操作

POST 因为是「新增或提交数据」的操作，不安全，不幂等

head

类似于get请求，只不过返回的响应中没有具体的内容，用户获取报头

查看服务器的性能，服务器支持的请求方式

特性

报文格式就是 header + body

缺点

分别是「无状态、明文传输、不安全」。

无状态

Cookie 技术。

客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了了

明文传输

对称加密

非对称加密/公钥私钥

安全

HTTPS 也就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层，

HTTP 协议是基于 TCP/IP

http1.1

长连接-持久连接

只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

只进行一次三次握手-减轻了服务器端的负载。

但是一次只能一个请求

管道网络传输

第一个请求发出去了，不必等其回来，可以发第二个请求出去

减少整体的响应时间

队头堵塞

服务器顺序响应

服务器只有处理完一个回应，才会进行下一个回应。
要是前面的回应特别慢，后面就会有许多请求排队等着

Http2.0

头部压缩

同时发出多个请求，他们的头是一样的或是相似的，会消除重复的部分。

全面采用了二进制格式

数据流

还可以指定数据流的优先级

帧

多路复用

多个请求复用一个TCP连接

解决队头堵塞

一个连接中TCP，客户端和浏览器都可以同时发送多个请求或回应，
而且不用按照顺序一一对应

多路复用归功于，帧（frame）和流（stream），二进制。
帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。
就是在一个 TCP 连接中可以存在多条流。

服务器主动推送消息

https://muyiy.cn/question/network/15.html

Http3.0

HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP（QUIC）

基于 UDP 的 QUIC 协议可以实现类似 TCP 的可靠性传输。

HTTPS

Https是具有安全性的SSL加密传输协议，即SSL+Http协议构建的可进行加密传输、身份认证的网络协议，比Http协议安全。
其作用主要是为浏览器和服务器之间的通信加密，确保数据传输的安全。

SSL协议需要SSL证书，而SSL证书是由受信任的数字证书颁发机构CA在验证服务器身份后颁发。

需要向 CA(证书权威机构)申请数字证书

服务器公钥放在数字证书中

SSL

Secure Sockets Layer 安全套接字协议

加入了 SSL/TLS 安全协议，使得报文能够加密传输。

四次握手

1. C->S: cilent hello的数据包,包含协议版本，加密算法等
2. S->C: Server Hello,加密算法,证书:含有服务端的公钥、CA数字签名等信息
3. C->S端验证信息，正确则发送给服务端预约密钥，然后用服务端返回的公钥进行加密传输
4. S->C:告知客户端，会使用刚刚协商的密钥来加密信息

TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。

信息加密

混合加密

通信之前进行非对称加密

公钥对内容进行加密，
然后只有私钥才能解密

由于非对称加密的性能低，因此用它来先协商对称加密的密钥即可，
后续真正通信的内容还是用对称加密的手段，提高整体的性能。

解决密钥配送问题

通信之后进行对称加密

加解密密钥相同

校验机制

摘要算法

身份证书

CA：公钥

确实是和正确的人通信

数字证书：公钥解密

https://developers.weixin.qq.com/community/develop/article/doc/000046a5fdc7802a15f7508b556413

HTTPS 的端口号是 443。

TCP

三次握手-四次挥手

为了建立可靠的通信信道

保证发送与接受都是正常的

双发收发功能都正常

自己发送、接收正常
对方发送、接收正常

为什么3次

TCP 连接

用于保证可靠性和流量控制维护的状态信息
Socket、序列号和窗口大小称为连接。

RFC：互联网标准

1. 才可以阻止重复历史连接的初始化(主要原因)
2. 才可以同步(确认保证)双方的初始序列号
3. 才可以避免资源浪费

1. 网络拥堵情况下:
一个「旧 SYN 报文」可能比
「最新的 SYN 」报文早到达了服务端;

如果是历史连接(序列号过期或超时)，则第三次握手发送的报文是 RST 报文，以此中止历史连接;
如果不是历史连接，则第三次发送的报文是 ACK 报文，通信双方就会成功建立连接;

2. 序列号是可靠传输的关键

保证数据包不重复、不丢弃和按序传输。

去除重复的数据;
按序接收;
标识对方已经收到;

3. 如果客户端重复发送多次 SYN 报文，【ack堵塞】

没有第三次握手，
服务器不清楚客户端是否收到了自己发送的建立连接的ACK 确认信号
那么服务器在收到请求后就会建立多个冗余的无效链接，
造成不必要的资源浪费。

「两次握手」:无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号;
「四次握手」:三次握手就已经理论上最少可靠连接建立无需。

握手(连接)

1. 客户端发送带有SYN标志(序号同步位)的数据包到服务端

客户端发起的 TCP 第一次握手 SYN 包，在超时时间内没收到服务端的 ACK，
就会在超时重传 SYN 数据包，每次超时重传的 RTO 是翻倍上涨的（1s+2s+4s+8s+32=63s），
直到 SYN 包的重传次数到达 tcp_syn_retries=5 值后，客户端不再发送 SYN 包。

2. 服务端发送带用SYN/ACK的标志的数据包到客户端

SYN：建立连接，确认通信

ACK：收到数据报，是你发的

S-处于SYN-ReCV状态

内核建立半连接队列

SYN攻击之

netstat -s

查看丢掉的 TCP 连接的个数

当第二次握手的 SYN、ACK 丢包时，客户端会超时重发 SYN 包，
服务端也会超时重传 SYN、ACK 包。

tcp_synack_retries = 5
进行重传

3. 客户端发送带有ACK标志的数据包到服务端

确认建立连接

可以携带数据

如果第三次握手的 ACK，服务端无法收到，
则服务端就会短暂处于 SYN_RECV 状态，而客户端会处于 ESTABLISHED 状态。

服务端一直收不到 TCP 第三次握手的 ACK，则会一直重传 SYN、ACK 包，
直到重传次数超过 tcp_synack_retries 值(默认值 5 次)后，服务端就会断开 TCP 连接。

客户端

传送数据

一直重传该数据包，直到重传次数超过 tcp_retries2 值(默认值 15 次)后，
客户端就会断开 TCP 连接。

没传送数据

保活机制

一直处于 ESTABLISHED 状态，然后经过 2 小时 11 分 15 秒
才可以发现一个「死亡」连接，于是客户端连接就会断开连接。

内核连接队列

半连接队列-
SYN 队列

第一 >> 二握手:服务端收到客户端发起的 SYN 请求后，
内核会把该连接存储到半连接队列，并向客户端响应 SYN+ACK

当半连接队列溢出后，
服务端就无法再建立新的连接。

开启 tcp_syncookies 功能解决

全连接队列
Accept 队列

第三次握手的 ACK 后，内核会把连接从半连接队列移除，
然后创建新的完全的连接，并将其添加到 accept 队列，
等待进程调用 accept 函数时把连接取出来。

如果进程不能及时地调用 accept 函数，就会造成 accept 队列溢出，
最终导致建立好的新的TCP 连接被丢弃（默认）

还可以选择向客户端发送 RST 复位报文

绕过三次握手

TCP Fast Open

第一次连接时还是三次握手，
但是TCP可选里多了Fast Open 选项带cookies

客户端缓存cookies信息，下一次请求时带上cookies与数据
如果服务端验证cookies成功，则对数据交给进程进行处理

减少了握手带来的 1 个 RTT 的时间
消耗。

挥手(断开)

1. 客户端发送FIN关闭C->S的连接（半关闭状态）

客户端不再发送数据了但是还能接收数据。

超时会重发其FIN

2. 服务端发送ACK表示收到了

服务端可能还有数据需要处理和发送

3. 服务端发送FIN关闭S->C的连接（半关闭状态）

超时会重发其FIN

tcp_orphan_retries

4. 客户端发送ACK确认关闭连接（完全关闭TCOP连接）

客户端在经过 2MSL 一段时间后，自动进入关闭状态

客户端接收到 FIN 后发送 ACK 开始计时的

打电话：A->B
A：我说完了；
B：好的；
B：继续说....我说完了;
A：好的；挂电话。

time-wait

主动关闭连接的，才有 TIME_WAIT 状态。

调用close()发起主动关闭的一方，在发送最后一个ACK之后会进入time_wait的状态

该发送方会保持2MSL时间之后才会回到初始状态

这个TCP连接在2MSL连接等待期间，定义这个连接的四元组不能被使用。
（客户端IP地址和端口，服务端IP地址和端口号）

MSL

最大报文段生存时间，它是任何报文在网络上存在的最长时间，

超过这个时间报文将被丢弃。

Linux 系统里 2MSL 默认是 60 秒

保证双方的连接都可以正常的关闭。

TTL

IP 头中有一个 TTL字段，是 IP 数据报可以经过的最大路由数

路由器此值就减 1

为什么需要 TIME_WAIT 状态?

防止具有相同「四元组」的「旧」数据包被收到;
为使旧的数据包在网络因过期而消失

经过 2MSL 这个时间，足以让两个方向上的数据包都被丢弃，
使得原来连接的数据包在网络中都自然消失，
再出现的数据包一定都是新建立连接所产生的。

保证「被动关闭连接」的一方能被正确的关闭，
即保证最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭;

如果未关闭，则一直处于LASE_ACK 状态

当客户端发起建立连接的 SYN 请求报文后，
服务端会发送 RST 报文给客户端，连接建立的过程就会被终止。

过多影响

第一是内存资源占用;

服务端线程占用

第二是对端口资源的占用，一个 TCP 连接至少消耗一个本地端口;

则会导致无法创建新连接【客户端】

https://blog.csdn.net/huangyimo/article/details/81505558

保活机制

已经建立了连接，但是某一段突然出现故障

每隔一个时间间隔，发送一个探测报文，
如果连续几个探测报文【保活探测次数】都没有得到响应，
则认为当前的 TCP 连接已经死亡

程序崩溃并重启

客户端会产生一个 RST 报文

断开重置连接

TCP参数

https://blog.csdn.net/zhangxinrun/article/details/7621028

包头格式

源、目的端口

确认数据发给哪个应用

序列号-32位

解决包乱序

操作系统随机初始化

ISN = M + F (localhost, localport, remotehost, remoteport)，F是hash算法

M=基于时钟的，每 4 毫秒 + 1

确认序号-32位

确认发出去对方能收到

序列号+1

解决不丢包问题

状态位

置1

SYN攻击

攻击者短时间伪造不同 IP 地址的 SYN 报文

占满服务端的 SYN 接收队列(半连接队列)，
而ack队列为空
使得服务器不能为正常用户服务。

解决

net.ipv4.tcp_syncookies = 1

当「 SYN 队列」满之后，后续服务器收到 SYN 包，不进入「 SYN 队列」;
计算出一个 cookie 值，再以 SYN + ACK 中的「序列号」返回客户端，

窗口大小

接收端告诉发送端自己还有多少缓冲区可以接收数据

MTU(最大传输单元) :一个网络包的最大长度，以太网中一般为 1500 字节。
MSS(最大报文段长度) :除去 IP 和 TCP 头部之后，一个网络包所能容纳的 TCP 数据的最大长度。

数据按MSS拆分

所有「分片都具有 TCP 头部」

序列号

TCP 分片丢失后，进行重发时也是以 MSS 为单位，
不用重传所有的分片，大大增加了重传的效率。

TCP MSS分片如果丢失了一片，
发送方没收到对方ACK应答，触发超时重传机制

如果按IP分片

以MTU为单位

当一个 IP 分片丢失，整个 IP 报文的所有分片都得重传。

IP 层本身没有超时重传机制，它由传输层的 TCP 来负责超时和重传。

每个被拆分的数据加上 TCP 头信息，然后交给 IP 模块来发送数据。

最大TCP连接数

IP数*端口数=2^32 * 2^16 = 2^48

特点

数据传递时：有确认、窗口、重传、拥塞控制机制

无差错、不丢失、不重复、按需到达

以MSS进行分片

数据传完后：还会断开连接用来节约系统资源

增加了许多开销，首部增大

TCP 的连接状态查看: netstat -napt

为什么TCP

IP 层是「不可靠」的，不保证网络包的交付、
不保证网络包的按序交付、也不保证网络包中的数据的完整性。

确保网络包是无损坏、无间隔、非冗余和按序的。

UDP

头部仅8字节

固定

不需首部长度字段

支持一对一、一对多、多对多的交互通信

尽最大努力交付，不保证可靠交付数据

如果中途丢了一个分片，则就需要重传所有的数据包

以MTU在IP层进行分片

应用

视频、音频，广播应用

DNS 、 SNMP

保证可靠传输

给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。

接收端会丢弃重复的数据。

校验和

首部和数据的检验和

检测数据在传输过程中的任何变化

如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。

重传机制

序列号与确认应答。

超时重传

设定一个定时器，当超过指定的时间后
未收到ACK 确认应答报文，则重传

数据包丢失
确认应答丢失

每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍。
两次超时，就说明网络环境差，不宜频繁反复发送。

RTT

往返时延

包的往返时间

RTO

重传超时时间

Retransmission TimeOut

应该略大于报文往返 RTT 的值

动态变化的值。

快速重传

收到三个相同的 ACK 报文时，
会在定时器过期之前，重传丢失的报文段。

重复确认

SACK

Selective Acknowledgment 选择性确认

TCP 头部「选项」字段里加一个 SACK字段

表明收到了哪些序列段数据包

开启只需要重传丢失的数据包。
如果不启用 SACK，就必须重传丢失包之后的每个数据包。

D-SACK

使用了 SACK 来告诉「发送方」有哪些数据被重复接收了。

网络延迟

流量控制

滑动窗口

每发送一个数据，都要进行一次确认应答
效率比较低的。

窗口大小

指无需等待确认应答，而可以继续发送数据的最大值。

假设窗口大小为 3 个 TCP 段，
那么发送方就可以「连续发送」 3 个 TCP 段

实现是操作系统开辟的一个缓存空间（内存缓冲区）

累计确认

中途若有 ACK 丢失，可以通过「下一个确认应答进行确认」

TCP头部字段

接收端告诉发送端自己还有多少缓冲区可以接收数据

由接收方的窗口大小来决定的

发送方窗口

三个指针来跟踪在四个传输类别

四类

已发送并收到 ACK确认的

已发送但未收到 ACK确认的

未发送但总大小在接收方处理范围内(可用窗口)

未发送但总大小超过接收方处理范围

三指针

snd.win:发送窗口大小

snd.una:指向为确认第一个序列号

snd.nxt:指向未发送但可发送范围

可用窗口为0时，
发送窗口探测报文

swnd = min(拥塞窗口，接收窗口)。

可用窗口大小 = SND.WND -(SND.NXT - SND.UNA)
(窗口大小-（未发送但在可发送范围内第一个 - 已发送待ack第一个))

发送窗口决定了一口气能发多少字节(较大)
而 MSS 决定了这些字节要分多少包才能发完。

接收方窗口

两个指针三个接收部分

已接受已确认，未接收但可接收，不能接收

RCV.WND:接收窗口的大小

RCV.NXT

指向期望从发送方发送来的下一个数据字节的序列号

通过 ACK 报文通知给对方

0窗口通知

当发送方接收到零窗口通知时，就会停止发送数据。

接着计时，发送方会定时发送窗口大小探测报文，
以便及时知道接收方窗口大小的变化。

超时时间会翻倍递增

滑动窗口实现流量控制

TCP 规定是不允许同时减少缓存又收缩窗口的，
采用先收缩窗口，过段时间再减少缓存，这样就可以避免了丢包情况。

先减少缓存，再收缩窗口，就会出现丢包的现象。

接收方应用程序来不及处理发送方的数据，
能提示发送方降低发送的速率，防止包丢失

糊涂窗口综合症

接收方腾出几个字节并告诉发送方，
而发送方会发送这几个字节

效率低下，大的开销

TCP + IP 头有 40 个字节

延迟确认与
Nagle 算法

TCP 报文中都会有 20 个字节的头部
如果传输数据较小(只有几个字节)，会很没效率

Nagle 算法
发送方

避免过多的小数据报文发送，这可提高传输效率。

策略

没有已发送未确认报文时，立刻发送数据。

即未收到第一个报文的确认前，
是不会发送后续的数据;

存在未确认报文时，直到「数据长度(窗口) >= MSS 大小」时，
再发送数据。

否则：囤积数据

一定会有一个小报文，也就是在最开始的时候

TCP 延迟确认

尽量等待与响应数据一起发送
否则延迟一段时间

第二个数据报文又到达了，
立刻发送 ACK

同时使用会造成额外的时延，都在等
建议只开一方

网络并未堵塞

流量控制是避免「发送方」的数据填满「接收方」的缓存区，
但是并不知道网络的中发生了什么。

拥塞控制

当网络拥塞时，减少数据的发送。
避免「发送方」的数据填满整个网络。

在网络出现拥堵时，如果继续发送大量数据包，可能会导致数据包时延、丢失等，
这时 TCP 就会重传数据，但是一重传就会导致网络的负担更重

发生了超时重传，就会认为网络出现了拥塞
即规定时间内没收到ACK

拥塞窗口 cwnd

发送方维护的一个的状态变量

发生堵塞就减少

发送窗口的值是swnd = min(cwnd, rwnd)

四个算法

慢启动
拥塞避免
拥塞发生
快速恢复

建立连接完成后，首先是有个慢启动的过程

当发送方每收到一个 ACK，(1-2-4-8)
每个拥塞窗口 cwnd 的大小就会加 1（指数增长）

发包的个数是指数性的增长。

cwnd 「超过」慢启动门限 ssthresh状态变量。
就会进入拥塞避免算法。(slow start threshold)

每当收到一个 ACK 时，cwnd 增加 1/cwnd。

指数增长变成了线性增长

当触发了重传机制，也就进入了「拥塞发生算法」。

超时重传

快速重传

cwnd=cwnd/2
ssthresh=cwnd

快速重传之后进入快速恢复

拥塞窗口 cwnd = ssthresh + 3

重传丢失的数据包

如果收到新数据的 ACK 后，把 cwnd 设置为第一步中的 ssthresh 的值

再次进入拥塞避免状态;

https://blog.csdn.net/ligupeng7929/article/details/79597423

ARQ协议

Automatic Repeat-reQuest：自动重传请求

停止等待

出现差错情况（超时重传）:

确认丢失

A->B,B-A丢失，A->B,
B再次收到该消息：1. 丢弃重复的消息 2. 向A发送确认消息。

确认迟到

收到两份确认消息，丢弃

连续ARQ协议

维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。

累计确认

提高信道利用率

每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。

IP

IP与Mac

IP 的作用是主机之间通信用的

MAC 的作用则是实现「直连」
的两个设备之间通信

IPv4

32 位正整数来表示

2^32个

分类地址。

A，B，C,D,E

A(0-7-24)

B(10-14-16)

D 类常被用于多播，E 类是预留的分类，

多播用于将包发送给特定组内的所有主机。

穿透路由的多播

224.0.0.0 ~ 239.255.255.255

缺点

太多或太少分配不均

A、B、C 类主要分为两个部分，
分别是网络号和主机号

最大主机个数，2^x-2

主机号全为 0 指定某个网络
主机号全为 1 指定某个网络下的所有主机，用于广播

广播地址用于在同一个链路中相互连接的主机之间发送数据包。"班长"

本地广播

被路由器屏蔽

直接广播

解决

CIDR无分类地址

a.b.c.d/x ，其中 /x 表示前 x 位属于网络号

子网掩码

掩码的意思就是掩盖掉主机号，剩余的就是网络号。

将子网掩码和 IP 地址按位计算 AND，就可得到网络号。

两台计算机要通讯，首先要判断是否处于同一个广播域内，即网络地址是否相同。
如果网络地址相同，表明接受方在本网络上，那么可以把数据包直接发送到目标主机。

路由器寻址工作中，也就是通过这样的方式来找到对应的网络号的

子网划分

如果两个(IP&子网)相同，则为同一子网下

ip 地址:网络地址+(子网网络地址+子网主机地址)

网络号+主机号

网络地址这一部分是用于进行路由控制。

主机和路由器上都会有各自的路由器控制表。
【网络号，下一跳】

找相同网络号-->下一个路由器

最长匹配

如果路由控制表中存在多条相同网络地址的记录，
就选择相同位数最多的网络地址

默认匹配【(0,0,0,0),下一跳】

没有找到与目标地址相同的网络地址，包被转发到默认路由

最终经过交换机把 IP 数据包转发到了目标主机

主机号

环路地址

localhost

特殊的 IP 地址 127.0.0.1 作为环回地址

使用这个 IP 或主机名时，数据包不会流向网络。

分片与重组

分片

最大传输单元 MTU

以太网的 MTU 是
1500 字节

当 IP 数据包大小大于 MTU 时， IP 数据包就会被分片。

(MSS)Maximum Segment Size

分片传输中，一旦某个分片丢失，则会造成整个 IP 数据报作废，
所以 TCP 引入了 MSS 也就是在 TCP 层进行分片不由 IP 层分片

TCP超时重传

对于 UDP 尽量不要发送一个大于 MTU 的数据报文。

重组

IP 数据报在被重组的时候，只能由目标主机进行，路由器是不会进行重组的。

IPv6

基本概念

128 位的

IPv4 和 IPv6 不能相互兼容

每 16 位作为一组，每组用冒号「:」隔开。

安全性和扩展性

可自动配置

不用 DHCP 服务器也可以实现自动分配IP地址

头部

固定 40 字节

去掉了包头校验和

提高了传输的性能

改进

取消了首部校验和字段。

取消了分片/重新组装相关字段。

提高了路由器转发的速度

取消选项字段。

IP头

源、目的IP

route -n 命令查看当前系统的路由表。

协议号

TCP-06(16进制)

TTL

生存周期，它的值随着每经过一次路由器就会减
1，直到减到 0 时该 IP 包会被丢弃。

为了在路由控制遇到问题发生循环状况时，避免 IP 包无休止地在网络上被转发。

ICMP

超时消息— 类型 11

发送给端主机

20字节