questions

体系结构

MAC头部：6
IP头部：20
TCP头部：20到60字节
UDP头部：8
TCP最大长度 65535 - 头部
UDP最大长度 65535 - 头部

RPC和HTTP（RESTFul）的区别

rpc

  1. 支持的协议：RPC支持多种协议，包括上层实现，比如grpc基于http2.0实现的，HTTP底层是TCP
  2. 消息的序列化：RPC，支持多种消息，protobuf/json等，HTTP底层是用json，xml封装的request的文本协议，进行序列化反序列化的
  3. http的请求头部很长，rpc的话一般可以压缩一些

    为什么微服务用grpc而不是http

    grpc 基于HTTP/2 提供了诸如多路复用、头部压缩等特性，可以显著提升通信效率

    get post put delete的区别【幂等性：操作多次，导致服务器到达的结果是想等的】

  4. get，一个具有幂等性的请求，参数在url后作为参数，只有get的请求数据会被缓存
  5. post，不具有幂等性，参数封装在请求体中，数据不会被缓存
  6. put一般放文件，delete用来删除文件，也都是幂等的

三次握手变成两次会发生什么

https://zhuanlan.zhihu.com/p/347519096
https://blog.csdn.net/lengxiao1993/article/details/82771768

  1. 第三次握手报文没有的话，二次握手维护的序列号没有第三次的确认号确认，服务端就无法确认客户端准备ok，触发超时重传，就无法协商它们的滑动窗口和拥塞窗口了

    四次握手第四次没确认的话会发生什么

    四次没确认就是

    四次握手最后一次time-wait状态为什么要等待两个MSL

    两个最大生存时间
  2. 为了保证A对第三次FIN挥手的确认报文到达B，如果没收到第四次的握手确认，B重传第三次挥手信号

    为什么不是一个MSL

    如果检测丢包所用的时间用了一个MSL，就根本没有接收到三次握手重传报文的机会了

    TCP的字节序是大端还是小端【大端】为什么？

    小端字节序是将最低有效字节存储在内存的最低地址处，而大端字节序则是将最高有效字节存储在最低地址处。
  3. 网络字节序是大端，arm64和x86主机采用主机字节序，是小端
  4. 如果两台主机的CPU架构或者字节序不同（比如一台是小端序，另一台是大端序），TCP协议会在传输过程中自动进行字节序的转换，以保证接收方能够正确地解析数据。
  • 创建socket或bind时，要用htonl、htons等函数来将端口或ip地址从主机字节序转换成网络字节序
  • send，recv等函数传输的只是字节流，不关心大小端序

    TCP如何保证可靠的

  1. 头部维护的校验和字段（CRC）
  2. 三次握手和四次挥手
  3. 超时重传（TTS字段）
  4. 流量控制（滑动窗口）
  5. 拥塞控制（拥塞窗口 + 慢启动）

    TCP半连接队列和全连接队列

    在TCP连接的建立过程中，会涉及到半连接队列（SYN队列）和全连接队列（ESTABLISHED队列）。
  • 半连接队列中存放的是三次握手中的第一步（即SYN）发送的连接请求，还没有得到完全建立连接的确认
  • 当TCP连接成功建立后，会被移动到全连接队列

    粘包和拆包

    由于网络传输中的数据分片、路由器缓冲区大小限制、接收端缓冲区大小设置等因素造成的
  • 粘包：多个数据包被合并成一个大的数据块
  • 拆包：只收到了一个大包，被拆成了多个小块
  • TCP选项字段可以设置MTU，指网络通信中能够通过的最大数据包的大小。通过设置MTU，可以控制单个数据包的大小，但并不能解决粘包和拆包的问题。
  • 粘包和拆包问题主要是因为TCP协议是流协议，它并没有记录消息的边界信息。因此，在数据传输过程中，可能会出现多个消息被合并成一个包（粘包）或一个消息被拆分成多个包（拆包）的情况。

TCP为什么要等待2MSL【为了保证最后一次握手成功】

因为服务端发送FIN以后，客户端发送第四次的挥手确认后，服务端可能接收不到，触发了重传，一个四次挥手的ACK和重传的FIN各占一个MSL

TCP最大长度为2的32次方-头部字段

解决办法【固定长度，消息边界，定时器，缓冲区】

  1. 头部字段，固定消息长度
  2. 帧数据字段加入边界信息，比如某个特定字符
  3. 使用定时器来等待足够长的时间以接收完整的消息，
  4. 可以通过合理设置缓冲区大小来保证完整接收消息

    TCP的TIMEWAIT状态过多会发生什么

    TCP的TIME_WAIT状态发生在第四次挥手，是为了确保在网络中所有的数据包都被正确地接收和处理，以避免出现数据包混淆或丢失的情况
  5. 内存资源、端口资源大量被占用，新连接无法建立，被网络攻击，导致程序崩溃等情况
  6. 拒绝服务（DOS）攻击，端口扫描攻击

    【如何解决】

  7. 在程序里设置一个等待参数，超时退出
  8. 使用连接池复用连接

    传输内容

    应用层 报文
    传输层 报文段
    网络层 数据包
    链路层 数据帧
    物理层 比特流

    网络层实现转发

    路由表是使用什么数据结构查找的？路由表中没有要查找的IP怎么办？

    路由表通常使用前缀树（Trie）存储路由表项，存的是一个IP地址与下一跳路由器，即路由器的IP地址，的映射
    没有要查找的IP，则跳到默认的下一跳，如果一直转发默认下一跳，则丢弃或者不可达信号

简述TCP的拥塞控制

首先，通过慢启动机制，当建立新的TCP连接时，发送方会谨慎地开始发送数据，逐步增大发送量以避免过快发送引起网络拥塞，每次x2。其次，一旦拥塞窗口达到设定阈值，TCP进入拥塞避免状态，发送方将以线性方式增大拥塞窗口，以保持合理的数据传输速率。

  1. 发现数据丢失时，用快速重传和快速恢复机制：1.计时器检测没有确认，超时重传发生，TCP会将拥塞窗口减半，再线性增加。

    简述TCP的流量控制【确保接收方能以自己的接收速度来处理】

    通过接收方维护接收的窗口实现的。
    发送方

    1. 应用层

    HTTP的无状态、明文传输特性

  • 无状态：在处理每个请求时都不会记住之前的请求，每个请求都是独立的，不依赖于之前的请求
  • 状态码：状态码用来指示服务器对请求的处理状态

    HTTP缓存

  • 强制缓存：浏览器判断缓存没有过期，则直接使用浏览器的本地缓存
  • 协商缓存：通过服务端告知客户端是否可以使用缓存的方式被称为协商缓存，响应状态码为304。
  • 【TIP】只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求。

HTTP 和HTTPs 的区别

  1. HTTP是明文传输，HTTPS使用了SSL证书来建立加密传输过程，HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。
  2. HTTP是直接运行在TCP协议基础上的，HTTPS是运行在SSL协议上，其中SSL协议建立在TCP之上，使用加密和身份验证保证安全性
  3. HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
  4. CA证书放在服务器上，证书内容包含服务器的公钥、持有者信息、颁发者信息、有效期等等
  5. CA证书验证：服务器向客户端发送证书时，客户端会使用相应的CA的公钥来验证证书的合法性。包括检查证书的数字签名是否正确、证书是否在有效期内等。
  6. CA信任链验证：如果客户端信任该CA（通常是因为CA的根证书预装在操作系统或浏览器中），那么客户端将信任由该CA签发的证书。

cookie和session,token的区别

https://zhuanlan.zhihu.com/p/625995458
https://zhuanlan.zhihu.com/p/164696755

1.区别

  1. cookie存在本地，session存在服务器上，cookie不安全，用户本地向服务器请求的申请，session用于会话控制，在服务端记录用户状态
  2. cookie存的字段都是字符串，session的话，跟随服务端数据类型
  3. cookie存的数据较少，最多4kb；session可以存的多，生命周期比短
  4. cookie主要字段如下：name expires domain path
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    session存的具体字段取决于你在应用程序中选择存储的信息。这些字段可以是任何你认为在会话期间需要跟踪和使用的数据。以下是一些可能存储在Session中的字段的例子：

    用户ID：用于标识当前会话所属的用户。
    示例：user_id: 12345
    用户名：用于显示在界面上或者用于显示欢迎消息等。
    示例：username: johndoe
    角色或权限信息：用于确定用户具有的权限级别或角色。
    示例：role: admin
    购物车内容：存储用户在购物网站中选择的商品信息。
    示例：cart: [item1, item2, item3]
    用户首选语言：用于提供多语言支持。
    示例：preferred_language: en
    上次访问时间：用于跟踪用户的活动情况。
    示例：last_visit: 2023-11-05 10:30:00
    登录状态：用于标识用户是否已登录。
    示例：logged_in: true
    安全令牌：用于防止CSRF等安全攻击。
    示例：csrf_token: abcdef123456
    用户设置：例如主题偏好、通知偏好等。
    示例：theme: dark

2.作用机制

cookie存了一个session ID，用户发请求时，cookie随请求body一起提交，然后session根据ID解析用户名密码，如果没找到，说明用户没登录或者失效

3. token是什么

token的生命周期： token的验证：再次请求时，携带此token，则服务端再次根据用户标识，生成token，根据两个token是否一致且未过期来判定用户是否已授权。

1
2
3
4
5
6
1. 客户端使用用户名跟密码请求登录
2. 服务端收到请求，去验证用户名与密码
3. 验证成功后，服务端会签发一个 token 并把这个 token 发送给客户端
4. 客户端收到 token 以后，会把它存储起来，比如放在 cookie 里或者 localStorage 里
5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 token
6. 服务端收到请求，然后去验证客户端请求里面带着的 token ，如果验证成功，就向客户端返回请求的数据
  1. 每一次请求都需要携带 token，需要把 token 放到 HTTP 的 Header 里
  2. 基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库
  3. token 完全由应用管理，所以它可以避开同源策略
  4. token由服务器生成并返回给客户端，是一种no-session的方式（当然也不需要cookie）。在Web应用程序中，Token通常是包含用户身份信息的加密字符串，JWT的工具类
  5. token使每一个请求都有签名还能防止监听以及重放攻击，而 Session 就必须依赖链路层来保障通讯安全了。如果你需要实现有状态的会话，仍然可以增加 Session 来在服务器端保存一些状态。
  6. Session 是一种记录服务器和客户端会话状态的机制，使服务端有状态化，可以记录会话信息。而 Token 是令牌，访问资源接口（API）时所需要的资源凭证。
  7. Token 使服务端无状态化，不会存储会话信息。
  • 安全做法：将accessToken存在内存中，refreshToken由backend通过set-cookie的方式存在http-only的cookie中

    5. jwt和session的优劣

  1. jwt是时间换空间，大量并发请求会导致压力比session方式压力大，然后在服务端生成jwt，每次请求都有新的jwt，如果用https请求发送，安全性也高一些
  2. jwt一旦创建就得等待过期，session适合用于大型项目

    6. 分布式session

  3. 共享session
    首先保证一个可用的redis集群，可以加redis服务器水平扩展，服务器重启session不会丢失
  4. session复制，在各服务器里复制，会造成网络负荷压力
  5. 粘性session，将请求重定向到某个有session的服务器上，负载均衡去转发，缺乏容错措施

权限认证

https://juejin.cn/post/7121237647829237768
https://juejin.cn/post/7288961029936578560

  1. JWY包括头部(Header)载荷(Payload)签名(Signature)三个部分

    rpc完整的调用过程

  2. 调用方持续把请求参数对象序列化成二进制数据，经过 TCP 传输到服务提供方；
  3. 服务提供方从 TCP 通道里面接收到二进制数据；
  4. 根据 RPC 协议，服务提供方将二进制数据分割出不同的请求数据，经过反序列化将二进制数据逆向
  5. 还原出请求对象，找到对应的实现类，完成真正的方法调用；
  6. 然后服务提供方再把执行结果序列化后，回写到对应的 TCP 通道里面；
  7. 调用方获取到应答的数据包后，再反序列化成应答对象。

    RPC的关键技术

HTTP状态码目录

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

  • 200：成功返回响应
  • 301：永久重定向，客户端第一次访问此 url 时，告知客户端以后直接访问新的 url，该状态保存在浏览器缓存中。
  • 302；临时重定向，客户端每次访问此 url 时，告知客户端重定向到新的 url ，后续访问依然访问当前的 url。
  • 304：使用协商缓存
  • 400：发送的请求错误，请求格式错误，或者没有服务器要求的数据。
  • 401：没有权限访问，当前用户没有权限访问此资源。
  • 403：请求被服务器禁止。
  • 404：请求的 url 不存在，一般是 url 出错。
  • 500：服务器处理请求出现错误。
  • 501：服务器超出能力之外的方法，例如：请求的方法服务器不支持。
  • 504：来自网关或者代理服务器，请求资源服务器时超时。

HTTP2：解决HTTP延迟高的问题

  • 延迟高的原因：请求-响应模型、头部巨大且重复、并发连接耗时、服务器不能主动推送等

    解决方法与针对的问题

  • 头部压缩：Cookie、User Agent、Accept 头部字段内容太大
  • 二进制帧：字段传输速度，便于位运算
  • 并发传输：缓解了队头阻塞问题（没有解决）
  • 服务端主动推送资源

    方法细节

  • 头部压缩：使用Hpack算法，静态字典/动态字典/哈夫曼编码。客户端和服务器两端都会建立和维护「字典」，用长度较小的索引号表示重复的字符串，再用 Huffman 编码压缩数据，可达到 50%~90% 的高压缩率。
  • 二进制帧：响应报文划分成了两类帧，包括 首部 和 DATA（负载），也就是说一条 HTTP 响应，划分成了两类帧来传输，并且采用二进制来编码。
  • 并发传输：使用 Stream 设计，多个 Stream 复用一条 TCP 连接，达到并发的效果

1
2
3
4
5
- 1 个 TCP 连接包含一个或者多个 Stream，Stream 是 HTTP/2 并发的关键技术；
- Stream 里可以包含 1 个或多个 Message，Message 对应 HTTP/1 中的请求或响应，由 HTTP 头部和包体构成；
- Message 里包含一条或者多个 Frame，Frame 是 HTTP/2 最小单位，以二进制压缩格式存放 HTTP/1 中的内容（头部和包体）；
- 一个 Frame 可以由多个 TCP 报文构成
- 不同stream的帧可以乱序，帧头部可以带stream ID，接收端可以重组
  • 服务端推送资源：客户端发起的请求，必须使用的是奇数号 Stream，服务器主动的推送，使用的是偶数号 Stream。服务器在推送资源时，会通过 PUSH_PROMISE 帧传输 HTTP 头部，并通过帧中的 Promised Stream ID 字段告知客户端，接下来会在哪个偶数号 Stream 中发送包体。

    HTTP3: quic协议，使用HTTP2 + TLS + UDP

    HTTP2存在问题：
  1. TCP层的队头阻塞问题：HTTP/2 多个请求是跑在一个 TCP 连接中的，那么当 TCP 丢包时，整个 TCP 都要等待重传，那么就会阻塞该 TCP 连接中的所有请求。
    • TCP 是字节流协议。TCP 层必须保证收到的字节数据是完整且有序的，如果序列号较低的 TCP 段在网络传输中丢失了，即使序列号较高的 TCP 段已经被接收了，应用层也无法从内核中读取到这部分数据，从 HTTP 视角看，就是请求被阻塞了。
  2. TCP 与 TLS 的握手时延迟：TCP 由于具有「拥塞控制」的特性，所以刚建立连接的 TCP 会有个「慢启动」的过程，它会对 TCP 连接产生“减速”效果
  3. 网络迁移需要重新连接：

    quic协议

  4. 无队头阻塞：传输层协议换成UDP，根本上避免了TCP的队头阻塞。
    • quic协议会保证数据包的可靠性，每个数据包都有一个序号唯一标识。当某个流中的一个数据包丢失了，即使该流的其他数据包到达了，数据也无法被 HTTP/3 读取，直到 QUIC 重传丢失的报文，数据才会交给 HTTP/3。
    • 而其他流的数据报文只要被完整接收，HTTP/3 就可以读取到数据。这与 HTTP/2 不同，HTTP/2 只要某个流中的数据包丢失了，其他流也会因此受影响。
  5. 更快的连接建立：quic协议握手的方式：
    • QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的“记录”，再加上 QUIC 使用的是 TLS 1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商，甚至在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果。
  6. 连接迁移：没有用四元组的方式来“绑定”连接，而是通过连接 ID 来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感。

网页解析HTTP请求：

  1. 输入url

  2. DNS解析，就近原则，如果本地DNS服务器的缓存中没有，就发到DNS根服务器，

    • 根DNS服务器返回的报文，告诉本地DNS，这个域名由哪个顶级DNS服务器负责，本地去这个顶级（比如.com）服务器去查询
    • 顶级返回次级地址，次级返回次次级，最后返回目标IP，本地DNS缓存更新这个IP
    • 其中用户使用的DNS服务器默认是运营商提供的本地域名解析器，检查自己的缓存

  3. 建立TCP连接，经过三次握手 1.C->S发送握手请求，附带一个SEQ=x，2.S->C发送收到，福袋一个ACK=x+1，和另一个SEQ=y ，3. C->S发送一个ACK=y+1 ,SEQ =x+1，上一个ACK，结束SYN-RECV阶段，并进入establish阶段/

  4. 释放连接，经过四次挥手 1.

    网页解析HTTPS请求：先建立TCP，再建立SSL加密

  5. 输入url，三次握手完成TCP通信建立

  6. 客户端发送https请求到服务端

  7. 服务端发回SSL证书和公钥到客户端

  8. 客户端验证证书安全性，如果安全，生成对称密钥，把这个密钥用公钥发回服务端

  9. 服务端用自己的私钥解密，这样两者都有了session key，后面的传输都是通过这个对称加密进行的

HTTP1.1的长连接是怎样建立的

响应头中包含了 Connection: keep-alive 字段，那么它表示愿意保持连接开启，后续的请求都会通过上一个连接发送

HTTP方法：POST GET的区别：get提交数据在url后，post在body中；get具有幂等性，post不具有

GET 方法具有幂等性，指同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。换句话说就是，幂等方法不应该具有副作用（统计用途除外）。
POST不具有幂等性。

  1. get 提交的数据会放在 url 之后，post 提交的数据放在 body 上。
    get请求参数会以 url 的形式完整的保留在浏览器的记录里，会存在安全问题。而 post 数据放在请求主体中，且数据不会被浏览器记录，相比 get 方法，post 方法更安全，主要用于修改服务器上的资源。

    • post 可以进行复杂的加密，get 则不可以

    • get 只支持 ASCII 字符格式的参数，而 post 方法没有限制。

    • get 提交的数据大小有限制（这里所说的限制是针对浏览器而言的），而 post 方法提交的数据理论上没限制

  2. get 方法具有幂等性，post 方法不具有。
    幂等性，同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。换句话说就是，幂等方法不应该具有副作用（统计用途除外）。

  3. post方法有时会发送两个 tcp 数据包，与浏览器有关

  • 使用 XMLHttpRequest 的 POST 方法时，浏览器会先发送 Header 再发送 Data。但并不是所有浏览器会这么做，例如火狐就不会。
  • 而 GET 方法 Header 和 Data 会一起发送
    XMLHttpRequest 是一个 API，它为客户端提供了在客户端和服务器之间传输数据的功能。它提供了一个通过 URL 来获取数据的简单方式，并且不会使整个页面刷新。这使得网页只更新一部分页面而不会打扰到用户。XMLHttpRequest 在 AJAX 中被大量使用。

长连接：减少 TCP 连接的重复建立和断开所造成的额外开销，减轻服务器端的负载。

  • 管道传输【一般不使用】：在同一个 TCP 连接里面，客户端可以发起多个请求：只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间
  • 队头阻塞问题：当顺序发送的请求序列中的某个请求阻塞时，后面的请求也会一直被阻塞。

    2. 传输层

    UDP

    UDP头部包含8个字节64位

UDP头部的格式如下：

源端口 (16位)：用于标识发送方的端口号。
目标端口 (16位)：用于标识接收方的端口号。
长度 (16位)：指示UDP报文头部和数据的总长度，以字节为单位，最小值为8（只有头部）。
校验和 (16位)：用于检测UDP报文是否在传输过程中发生了错误。

TCP

TCP头部包含20个字节。握手挥手时，数据字段为空

*为什么要进行三次握手 ？

确认客户端和服务端都可以正常发送接收数据。

  • 第一次握手：确认客户端可以正常发送数据。
  • 第二次握手：确认客户端可以正常发送数据，确认服务端可以正常接收数据。
  • 第三次握手：确认客户端可以正常发送数据，确认服务端可以正常接收数据，确认服务端可以正常发送数据，客户端可以正常接收数据。

    三次握手过程中网络断开，会出现什么情况

第一次握手丢失：客户端没收到第二次握手，触发超时重传机制，发送第一次握手
第二次握手丢失：客户端依然没收到第二次握手，触发超时重传，发送第一次握手；服务端没有收到第三次握手，超时重传，发送第二次握手
第三次握手丢失：客户端establish状态，服务端没有收到第三次握手，超时重传，仍然发送第二次握手

超时重传的限度：发送一定次数N，这个次数由内核限制，linux为5次。

为什么要进行四次挥手 ？

第一次挥手：客户端向服务端请求关闭连接。

  • 客户端：客户端无数据传输。
  • 服务端：无感知。

第二次挥手：服务端收到客户端的请求，并且告知客户端等我处理完毕数据。

  • 客户端：客户端无数据传输。
  • 服务端：客户端无数据传输。

第三次挥手：服务端处理完毕数据，告知客户端，服务端数据处理完毕。

  • 客户端：客户端无数据传输，服务端无数据传输。
  • 服务端：客户端无数据传输，服务端无数据传输。

第四次挥手：客户端得知服务端数据处理完毕，双方数据都处理完毕，可断开连接。

  • 客户端：客户端无数据传输，服务端无数据传输。
  • 服务端：客户端无数据传输，服务端无数据传输，得知客户端知道服务端无数据传输。

*TCP是如何保证可靠传输的

1 数据分块
​ 应用数据被分割成 TCP 认为最适合发送的数据块。并且给每一个数据块进行编号，在传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答，即发送 ACK 报文，这个 ACK 报文当中带有对应的确认序列号，如果发送过程中，存在数据块丢失或者发送重复，接收方根据序列号整理数据块，删除重复的数据块，要求发送方重新发送丢失的数据块。

2 校验和
与UDP 校验和相同，监测数据传输过程中可能出现的差错。

3 流量控制
让发送方的发送速率不要太快，让接收方来得及接收，TCP 连接的双方都有一个固定大小的缓冲空间，发送方发送的数据量不能超过接收端缓冲区的大小。当接收方来不及处理发送方的数据，会提示发送方降低发送的速率，防止产生丢包。TCP 通过滑动窗口协议来支持流量控制机制。

4 ARQ协议
ARQ(Automatic Repeat-reQuest)自动重传协议：每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。

5 超时重传
当 TCP 发出一个报文段后，它启动一个定时器，等待目的端确认收到这个报文段。如果超过某个时间还没有收到确认，将重发这个报文段。

6 拥塞控制
在实际的网络通信系统中，除了发送方和接收方外，还有路由器，交换机等复杂的网络传输线路，此时就需要拥塞控制。拥塞控制是作用于网络的，它是防止过多的数据注入到网络中，避免出现网络负载过大的情况。常用的解决方法有：慢开始和拥塞避免、快重传和快恢复。

慢开始：当发送方开始发送数据时，由于一开始不知道网络负荷情况，如果立即将大量的数据字节传输到网络中，那么就有可能引起网络拥塞。一个较好的方法是在一开始发送少量的数据先探测一下网络状况。慢开始的慢指的是初始发送报文段的数量为 1，如果收到确认，则发送两个报文段，之后每收到一个确认报文，发送报文端的数量就翻倍，直到到达慢开始门限，当发送报文段的数据大于门限数量时，使用拥塞避免算法。
拥塞避免：当网络拥塞发生时，慢开始门限值减半，发送的报文段数量改变为 1 ,然后再次重复两种算法（慢开始和拥塞避免）。
快重传：接收方每收到一个失序的报文就立即发送重复确认，而不要等到自己发送数据时才捎带进行确认，假定发送方发送了 Msg 1 ~ Msg 4 这 4 个报文，已知接收方收到了 Msg 1，Msg 3 和 Msg 4 报文，此时因为接收到收到了失序的数据包，按照快重传的约定，接收方应立即向发送方发送 Msg 1 的重复确认。 于是在接收方收到 Msg 4 报文的时候，向发送方发送的仍然是 Msg 1 的重复确认。这样，发送方就收到了 3 次 Msg 1 的重复确认，于是立即重传对方未收到的 Msg 报文。由于发送方尽早重传未被确认的报文段，因此，快重传算法可以提高网络的吞吐量。

快恢复

快恢复算法是和快重传算法配合使用的，该算法主要有以下两个要点：

① 当发送方连续收到三个重复确认，执行乘法减小，慢开始门限值减半；

② 由于发送方可能认为网络现在没有拥塞，因此与慢开始不同，发送报文段的数量减半，然后执行拥塞避免算法，线性增加发送报文段的数量。

quic协议

QUIC(Quick UDP Internet Connections)，是一种基于 UDP 的传输层协议。QUIC = HTTP/2 + TLS + UDP.

3. 网络层

IP

A 类地址：10.0.0.0～10.255.255.255
B 类地址：172.16.0.0～172.31.255.255
C 类地址：192.168.0.0～192.168.255.255
解决IPv4不够用的两种技术：

  • nat(network address translation)网络地址转换协议：将内网地址转为公网ip的协议，实现多层网络地址转换。
  • IPv6 128位，比IPv4的32位多了四倍

    链路层

    ARP协议

    arp(address resolution protocol) 地址解析协议：根据主机的ip 地址获取主机的mac 地址。每个主机都有一个 ARP 高速缓存，里面有本局域网上的各主机和路由器的 IP 地址到 MAC 地址的映射表。

A要发送B一个数据包，首先他有B的IP地址，为了发送成功还需要B的MAC地址。

  • 首先A查找本地ARP缓存，IP：MAC的映射
  • 如果找到MAC 地址，就可以发送消息。
  • 如果没有，A就会发送一个局域网广播的ARP请求B的MAC的数据包，这个消息被局域网内所有的计算机接受，B返回一个包含自身MAC和IP地址的ARP响应消息。作为响应请求的一部分，B 可以将 A 的一个条目插入到它的 ARP 表中，以备将来使用。

MAC地址

  • MAC 地址是数据链路层和物理层使用的地址，是写在网卡上的物理地址。MAC 地址用来定义网络设备的位置。
  • IP 地址是网络层和以上各层使用的地址，是一种逻辑地址。IP 地址用来区别网络上的计算机。
    互联网中主机之间相互传递数据的逻辑是，先通过 ip 地址找到对应的局域网，然后再找到对应的主机。
  • 如果只采用 ip 地址，不用mac 地址：不安全， 同一个ip 地址可能绑定多个主机，而无论何时mac 地址和主机是一一对应的。
    找不到主机号，IP本质上相当于逻辑地址，两个主机可能有一个IP
  • 如果只采用mac 地址，不用ip 地址：没有办法使用ip 通过网段寻找目标主机，需要在全网段内没有规律的找一个主机，效率太慢。
    一个是不够用，二是没有IP网段，全网查找，没有规律

WebSocket

  • 使用最广泛的HTTP/1.1，也是基于TCP协议的，同一时间里，客户端和服务器只能有一方主动发数据，这就是所谓的半双工。

1. 正向代理和反向代理

  1. 正向代理是为了隐藏客户端信息例如ip，反向代理是为了隐藏服务器信息，例如ip。
  2. 正向代理是有感知的（就是说你需要用vpn你需要自己去配置），反向代理是无感知的（只需要输入www.baidu.com就可以访问到百度不同服务器上的资源，配置过程不是用户去做的）。