TCP三次握手

三次握手的机制是为了保证能建立一个安全可靠的连接
http 的本质就是 tcp/ip 请求
需要了解 3 次握手规则建立连接以及断开连接时的四次挥手
tcp 将 http 长报文划分为短报文，通过三次握手与服务端建立连接，进行可靠传输
TCP：稳定的网络通信协议【优点：稳定很多校验】
UDP:不稳定的网络通信协议【优点速度快，一般用于音视频的传输】

数据包格式

一行32bit，8字节

4. TCP三次握手 - 图1

序号

  1. seq[sequence number]序列号
    1. 序列号用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记，保证数据包顺序

  2. ack[acknowledge number]确认序号

    1. 只有ACK标志位为1时，确认序号字段才有效，ack=seq+1

      标志位

  3. SYN[Synchronize ]：同步序列编号 0/1

    1. 建立连接时发送
    2. 带有seq
  4. ACK[Acknowledge ] :确认字符 0/1
    1. 确认连接时发送（发送的是收到的seq+1）
    2. 带有ack
  5. FIN ：关闭连接
  6. PSH ：有 DATA 数据传输
  7. RST ：连接重置

4. TCP三次握手 - 图2

建立连接

  1. 第一次握手：客户端主动向服务器端发送SYN=1同步包（包里面带有初始序列号seq = x（32位 ）），客户端进入SYN_SENT状态
  1. 第二次握手：服务器收到客户端SYN包，就要发送ACK=1确认包（ack = x+1），除此之外还要发送SYN=1同步包（seq = y），服务器端进入SYN_RECEIVED状态
    1. 因为只知道客户端能发，所以还要发一个SYN来确认客户端能不能正确接收
  1. 第三次握手：客户端接收SYN包，需要确认服务器端的SYN包，发送ACK=1（ack = y+1）
    1. 此时客户端知道了 服务器 能正常 接收 和 发送

  1. 最后服务器接收：服务器端接收，客户端和服务器端进入Eestablished状态，可以开始正式传输数据

    1. 此时服务器知道了 客户端 能正常 接收 和 发送


      数据传输

      HTTP报文：
    • 请求报文
    • 响应报文

响应状态码：

HTTP状态码 HTTP状态码描述 中文描述
200 OK

| | 202 | Accepted | 服务器已接受请求，但尚未处理（异步） | | 204 | No Content | 服务器成功处理了请求，但不需要返回任何实体内容（head请求） | | 301 | Moved Permanently | 永久转移 「域名迁移」 | | 302 | Move Temporarily | 临时转移 「负载均衡」 | | 304 | Not Modified | 缓存 | | 305 | Use Proxy | 代理 | | 400 | Bad Request | 请求参数有误 | | 401 | Unauthorized | 权限（Authorization） | | 403 | Forbidden | 服务器拒绝执行「为啥可能会已响应主体返回」情况很复杂，后端最好不要返回这玩意 | | 404 | Not Found | 地址错误 | | 405 | Method Not Allowed | 请求方式不被允许 | | 408 | Request Timeout | 请求超时 | | 500 | Internal Server Error | 未知服务器错误 | | 503 | Service Unavailable | 超负荷 | | 505 | HTTP Version Not Supported |

| |

|

|

|

三次握手为什么不用两次，或者四次?

  1. 不是两次：
    1. 第二次握手后，只有客户端知道服务器端能够正确接收发送
    2. 服务器端不知道客户端能否正确接收发送
  2. 不是四次：
    1. 四次握手导致资源浪费

三次握手过程可以携带数据吗？

  1. 第一二次不可以
    1. 第一次就能带大量数据，攻击者就很容易让服务器花很多时间、空间来接收报文
  2. 第三次可以
    1. 于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

SYN攻击？

  1. 做什么：
    1. 攻击者伪造的大量假IP，发送 SYN同步包
    2. 等服务器返回SYN+ACK后，客户端就不发ACK，TCP连接变成半连接状态
    3. 服务器因此被占用大量资源，无法正常运行
  2. 防范：
    1. 降低 SYN 超时时间
    2. 防火墙

TCP如何保证可靠传输？

  1. 校验和
    1. 通过检验和的方式，接收端可以检测出来数据是否有差错，有差错就会重传
    2. 加上一个 12 字节的伪首部（从IP数据报获取）
      1. 序列号/确认号
    3. 发送方发送报文的时候带着一个序列号
    4. 接收方收到报文就会确认，确认的时候确认号就是收到的序列号+1，保证了TCP报文的顺序
      1. 重传机制
    5. 发送方发送一段时间后没有收到确认就重传
    6. 每一个报文都有计时器，超时重传时间要根据网络的状况来决策
      1. 滑动窗口（缓冲区）
    7. 为啥要有？
      1. 滑动窗口就是说，发送端在收到 一个报文的确认前，想要继续发送其他报文，这样可以提高信道的利用率
      2. 但是，排在前面发送的报文可能有出错，需要重传，所以要一个缓冲区来维护这些报文
    8. 窗口的大小：在无需等待确认包的情况下，发送端还能发送的最大数据量。这个机制的实现就是使用了大量的缓冲区，通过对多个段进行确认应答的功能。通过下一次的确认包可以判断接收端是否已经接收到了数据，如果已经接收了就从缓冲区里面删除数据
      1. 拥塞控制（发送速度）
    9. 为啥要有？
      1. 窗口控制解决了 两台主机之间因传送速率而可能引起的丢包问题，在一方面保证了 TCP 数据传送的可靠性
      2. 然而如果网络非常拥堵，此时再发送数据就会加重网络负担，那么发送的数据段很可能超过了最大生存时间也没有到达接收方，就会产生丢包问题
      3. 为此 TCP 引入慢启动机制，先发出少量数据，就像探路一样，先摸清当前的网络拥堵状态后，再决定按照多大的速度传送数据
    10. TCP慢启动：
      1. 慢启动：在启动初期以指数增长方式增长，设置一个慢启动的阈值
      2. 线性增长：当以指数增长达到阈值时就停止指数增长，按照线性增长方式增加至拥塞窗口
      3. 新的慢启动：线性增长达到网络拥塞时立即把拥塞窗口置回 1，进行新一轮的 “慢启动”，同时新一轮的阈值变为原来的一半

TCP和UDP的区别？

  1. 传输可靠性
    1. TCP提供可靠的数据传输服务，还有流量控制、拥塞控制等服务
    2. UDP提供的是不可靠的数据传输服务
  2. 连接
    1. TCP是面向连接，基于数据流，双方有缓冲区，要确保数据都到达了，总体速度慢
    2. UDP是无连接的，基于数据报，双方没有缓冲区，如果没收到就不会再传了，所以速度快
  3. 应用场景
    1. TCP由于是可靠传输，所以负责服务那种需要数据准确无误传输的应用层协议，HTTP、FTP（文件）、SMTP（邮件）
    2. UDP由于是不可靠传输，速度快，所以负责语音传输、视频直播这种要求尽量实时的应用