汇总2

OSI七层协议模型 TCP/IP四层体系结构

TCP为什么要三次握手？

还可以这样子问：

• 为什么最后还要发送一次确认？
• 为什么是三次握手，而不是四次或两次？

三次握手是保证双方都得知自已和对方收发能力正常 的最低值；四次也可以但是显得比较多余
为了防止已失效的连接请求报文段突然又传到了服务端（解释：报文段已发送，在某个网络节点发生滞留，导致连接释放,释放后报文才到达另一端），产生错误（预防SYN洪泛攻击）。同时保证发送双方的消息发送与接收功能都可用。

TCP为什么要进行四次挥手？

因为是双向连接。两次握手只是断开单向连接,双向断开就需要四次握手

• TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。
• TCP是全双工模式，主机1请求关闭连接，不再发送数据了，但是可以接收主机2的数据，主机2不再发送数据了，才算关闭，这样减小了丢失数据的风险。

三次握手中的丢包问题

1. SYN 丢包如何处理？

客户端会尝试重发，超过设定的次数仍未收到 ACK 则会不了了之。

2. SYN+ACK丢包如何处理？

一旦超时，服务端会重发该报文段。但如果重发了超过设定的次数，服务端仍未收到 ACK 报文段的话，服务端会自动关闭该连接。
但此时客户端仍无法感知到连接的关闭，因此服务端还会向客户端发送 RST 报文段，让客户端感知到并重置此连接。

3. 三次握手中最后 ACK 丢包如何处理？

服务端收不到 ACK 会进行重传，此时客户端会认为连接已建立，处于 ESTABLISHED，而服务端仍处于 SYN_RCVD，此时如果服务端收到了客户端的数据包，会认为连接已建立，进入 ESTABLISHED。

为什么TIME_WAIT状态还需要等2*MSL（最大分段生存期）秒之后才能返回到CLOSED状态呢？

我们必须假想网络是不可靠的，你无法保证你最后发送的ACK报文一定会被对方收到，就是说对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。

输入一个网址/发起一个 HTTP 请求的过程？

• 首先判断是否需要进行域名解析，如果需要会走一个 DNS 域名解析的过程，得到对应的目标 IP 地址
• 接着，HTTP 会去进行 TCP 的三次握手建立 TCP 连接
• 发送 HTTP 请求，封装 HTTP 请求报文，下放到运输层继续封装 TCP 报文，添加源、目的 IP和端口
• 下到网络层，通过 IP 协议和路由选择，根据源、目的 IP 去查询路由表并确定到达目的 IP 的路径
• 下到数据链路层，通过 ARP 协议查找 IP 地址的 MAC 地址，封装成 MAC 数据帧，传输到目的主机上
• 目的服务器收到数据包后再进行逐层的解析最终得到 HTTP 请求信息并给予响应
• 客户端收到响应信息后再进行对应的数据渲染呈现给用户

涉及到的协议：

1. 应用层：HTTP，DNS（DNS解析域名为目的IP，通过IP找到服务器地址，客户端向服务器发起HTTP会话，然后通过传输层TCP协议封装数据包，在TCP协议基础上进行传输）
2. 传输层：TCP（为HTTP提供可靠的数据传输），UDP（DNS使用UDP传输）
3. 网络层：IP（IP数据数据包传输和路由选择），ICMP（提供网络传输过程中的差错检测），ARP（将本机的默认网关IP地址映射成物理MAC地址）

HTTP协议和TCP协议的区别

1. 性质不同：
   1. HTTP是简单的请求响应协议（应用层协议）
   2. TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议（传输层协议）
2. 连接不同：
   1. HTTP运行于TCP之上，指定了客户端可能发送给服务器怎么样的消息以及得到怎么样的响应
   2. TCP连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务
3. 功能不同：
   1. HTTP协议是基于请求/响应范式的
   2. TCP把数据流分割成适当长度的报文段

TCP协议如何保证可靠传输

• 校验和
  • 发送方： 在发送数据之前计算检验和，并进行校验和的填充
  • 接收方：收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方的进行比对
• 确认应答和序列号
• 超时重传
• 连接管理
• 流量控制
• 拥塞控制

SYN洪泛攻击

Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪

https如何建立连接？

SSL/TLS四次握手

1. 客户端—>服务器 加密通信请求：随机数A、支持的TSL版本、支持的加密套件列表等
2. 服务器—>客户端 响应请求：随机数B、确认TSL版本、数字证书、确认加密套件列表
3. 客户端—>服务器 确认证书无错，获取服务器公钥，加密报文，发送信息：公钥加密后的随机数C、通知更改加密通信算法、握手结束通知
4. 服务器—>客户端 解密得到随机数C，根据协商的算法加密ABC得到对称加密的密钥，发送信息：更改加密通信算法、握手结束通知

HTTP常见的状态码有哪些

• 200 正常
• 204 类似200，不过响应头没有body数据
• 301 永久重定向，表示请求的资源已经不存在，要改用新的URL再次访问
• 302 临时重定向，和301都会在响应头使用字段Location指明跳转的URL。浏览器自动跳转
• 304 缓存重定向，重定向到已存在的缓冲文件
• 400 客户端请求的报文出错
• 403 服务器禁止访问资源
• 404 请求的资源不存在或找不到
• 500 服务器出错
• 502 服务器作为网关或代理时返回的错误码
• 503 服务器忙，暂时无法响应
• 504 网关超时 一般计算机中的超时就是配置错了，此处一般指nginx做反向代理服务器时，所连接的服务器tomcat无响应导致的。

说一下TCP里面的拥塞控制、流量控制

拥塞控制：监控网络拥堵情况调整和遏制发送方发送速率减少因网络拥塞导致的过多丢包事件的机制。
流量控制：避免「发送方」的数据填满「接收方」的缓存，但是并不知道网络的中发生了什么。

• 拥塞控制是针对网络的，防止过多的数据进入网络中，导致网络的负载过大。它是通过一个叫 cwnd 的拥塞窗口实现的，主要是在发送方通过监听网络中丢包事件来判断网路的拥塞状况，从而调整自己的发送速度。
• 流量控制是针对接收者的，主要是控制发送方的发送速度，避免接收者来不及接收处理导致分组丢失的情况。它是通过一个滑动窗口来实现的，在发送方和接收方都维护一个滑动窗口，由接收方来告知发送方自己的情况从而一起调整窗口的大小。

TCP里面遇到滑动窗口为0会发生什么

发送方不会再发信息，即使接收方已经处理完了，又有了空闲信息
处理方法：进行零窗口探测，即使RcvWindow=0，发送方仍然可以发送一个很小的段，从而带回来新的RcvWindow信息。如果接收方回复窗口大小仍然为零，则发送方的探测定时器加倍。没有收到ACK时，发送探测包的最大次数之后连接超时。

拥塞控制算法

• 慢开始
• 拥塞避免
• 快重传
• 快恢复

IPv4和IPv6的区别（IPv6的主要变化）

1. 更大的地址空间（从32位->128位）
2. 扩展的地址层次结构
3. 灵活的首部格式（可提供比ipv4更多的功能 ）
4. 改进的选项（ipv6首部长度是固定的，选项放在有效载荷中；ipv4选项放在首部的可变部分）
5. 允许协议继续扩充（ipv4功能是固定不变的）
6. 支持即插即用【即自动配置】（ipv6不需要使用DHCP）
7. 支持资源的预分配
8. ipv6首部改为8字节对齐【首部长度必须是8字节的整数倍】（ipv4是4字节对齐）

ARQ协议

发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。
接收方一般采用累计确认的方式，接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，就表示到这个分组为止的所有分组都已确认收到

累计确认的优点：

• 容易实现
• 及时确认丢失也不必重传

缺点：

• 不能向发送方反映出接收方已经正确收到的所有分组信息

ARQ的负面影响：
如果前五个分组，中间第三个丢了，只能对前两个分组发送确认，后面三个分组需要进行重传（Go-back-N）
Go-back-N：表示需要再退回来重传已经发送过的N个分组