docs: add tcp docs

src/en/guide/concepts/network/2-tcp-udp.md

@@ -0,0 +1,69 @@
+---
+order: 2
+title: "TCP/UDP"
+---
+### TCP
+
+Transmission Control Protocol (TCP) is a connection-oriented, reliable, byte-stream-based transport layer communication protocol.
+
+#### TCP Header Structure
+
+![tcp header](/assets/image/article/network/tcp_en.png)
+
+| TCP Header Field | Description |
+| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Source Port | Sender's port number, range (0~65535) |
+| Destination Port | Receiver's port number, range (0~65535) |
+| Sequence Number | If the TCP data is too large (greater than the allowable degree of IP packet), it needs to be segmented. This sequence number records the sequence number of each packet, allowing the receiver to reassemble the TCP data. The value of the sequence number field refers to the sequence number of the first byte of data sent by this segment. Abbreviated as `seq` |
+| Acknowledgment Number | To confirm that the receiver has indeed received the packet data sent out by the sender, when the sender receives this acknowledgment code, it can confirm that the previous packet has been correctly received. This acknowledgment number is the sequence number of the first byte of data from the next segment expected to be received from the other party. Abbreviated as `ack` |
+| Header Length | Indicates the length of the TCP header, range (0~15), unit 32bit, for example, when the value is 5, it means that the header length is 20Byte(160bit), if the option field is empty, then the TCP header length is 20Byte, that is, the value is 5 |
+| URG | `URG=1` indicates that there is urgent data, the last byte of the urgent data is pointed out by the urgent data pointer, generally less used |
+| ACK | `ACK=1` indicates that the value in the acknowledgment number field is valid, 0 indicates invalid |
+| PSH | `URG=1` indicates that the urgent pointer field is valid, representing that this packet is an urgent packet. It tells the system that there is urgent data in this segment and should be transmitted as soon as possible (equivalent to high-priority data) |
+| RST | `RSP=1` rebuilds the connection, if the RST bit is received, some errors usually occur |
+| SYN | `SYN=1` indicates that this is a connection request or connection acceptance message, generally used in the handshake stage |
+| FIN | `FIN=1` indicates that the data of the sender of this segment has been sent and requests to release the transport connection |
+| Receive Window | Used for flow control, indicating the number of bytes the receiver is willing to receive, range `0~65535` bytes |
+| Checksum | The checksum covers the entire TCP segment, i.e., the TCP header and TCP data. This is a mandatory field, it must be calculated and stored by the sender, and verified by the receiver |
+| Urgent Data Pointer | When `URG=1` is valid, it is a positive offset, and the sum with the value in the sequence number represents the sequence number of the last byte of urgent data |
+| Options | Used when the sender and receiver negotiate the maximum segment length (MSS) (only exists in SYN messages) or used as a window adjustment factor in high-speed network environments, can also store timestamp data |
+
+#### TCP State Machine
+
+![TCP Stateful](/assets/image/article/network/tcp_state_en.png)
+
+#### TCP Three-Way Handshake
+
+![TCP Connection](/assets/image/article/network/tcp-connect.png)
+
+::: tip Three-Way Handshake Process
+1. The client sends `SYN=1`, and specifies the client's initial sequence number `ISN`, i.e., `x`.
+2. The server sends its own `SYN` segment as an acknowledgment, also specifying its own `ISN`, i.e., `y`. To acknowledge the client's `SYN`, it sets `ACK` to `x+1`. In this way, each time a `SYN` is sent, the sequence number will increase by 1. If there is a loss, it will be retransmitted.
+3. To acknowledge the server's `SYN`, the client sets `ACK` to `y+1` in the returned value.
+
+:::
+
+::: tip TCP Four-Way Handshake
+1. The client sends `FIN=1`, and includes its current sequence number `x+2`. It also includes an `ACK=y+1` to acknowledge the data most recently received from the other side.
+2. The server adds 1 to the value `x+2` as the `ACK` sequence number, indicating that the previous packet has been received. At this time, the upper-layer application will be notified that the other end has initiated a shutdown operation, which usually causes the application to initiate its own shutdown operation.
+3. The server initiates its own `FIN=1`, `seq=y+1`.
+4. The client acknowledges, sends `ACK=y+2` to the server.
+:::
+
+::: warning Why is a three-way handshake needed? What is its purpose?
+
+::: details
+The process of TCP establishing a connection is the process of synchronizing sequence numbers, SYN (Synchronize Sequence Numbers) is to synchronize sequence numbers. Therefore, the purpose of the three-way handshake is to allow the client (Client) and the server (Service) to obtain each other's sequence number.
+:::
+
+::: warning Why is a four-way handshake needed? What is its purpose?
+
+::: details
+The reason why a four-way handshake is needed is because TCP is a **full-duplex** protocol, i.e., both the client and the server can actively send messages, so both ends need to send disconnect instructions after the transmission is completed, and need to send `FIN=1` separately to disconnect, and use `ACK` to determine whether the sending was successful.
+:::
+
+::: danger What happens if SYN times out during connection?
+
+::: details
+If the client sends a `SYN` command, and drops the line before the server returns the `SYN` command, the server will try to resend the `SYN-ACK` command. Under Linux, the default is to retry 5 times, the interval time starts to double from 1s, i.e., `1s, 2s, 4s, 8s, 16s`, so the timeout time is `1s + 2s + 4s+ 8s+ 16s + 32s = 63s`. After the timeout, TCP will disconnect.
+:::

src/guide/concepts/network/network.md → src/guide/concepts/network/1-network.md

@@ -137,12 +137,12 @@ HTTP 1.1 额外支持 6 种请求方式
 
 
 ::: tip 区别
-| 特性 | HTTP 1.0 | HTTP 1.1 | HTTP 2.0 |
-|--------|-----------------------------|------------------------------------|-----------------------------------|
-| 连接方式 | 无连接，每次请求都要建立连接 | 长连接，减少了 TCP 连接的重复建立和断开所造成的额外开销 | 多路复用，一个 TCP 连接上可以并发多个 HTTP 请求 |
-| 队头阻塞 | 存在，下一个请求必须在前一个请求响应到达之前才能发送  | 存在，虽然可以发起多个请求，但服务器必须按照接收请求的顺序发送响应  | 解决，可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应  |
-| 头部压缩 | 不支持 | 不支持 | 支持，使用 HPACK 算法对 header 进行压缩 |
-| 服务器推送  | 不支持 | 不支持 | 支持 |
+| 特性  | HTTP 1.0  | HTTP 1.1  | HTTP 2.0  |
+| ---------- | ---------------------------------------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------- |
+| 连接方式 | 无连接，每次请求都要建立连接  | 长连接，减少了 TCP 连接的重复建立和断开所造成的额外开销  | 多路复用，一个 TCP 连接上可以并发多个 HTTP 请求  |
+| 队头阻塞 | 存在，下一个请求必须在前一个请求响应到达之前才能发送 | 存在，虽然可以发起多个请求，但服务器必须按照接收请求的顺序发送响应 | 解决，可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应 |
+| 头部压缩 | 不支持  | 不支持  | 支持，使用 HPACK 算法对 header 进行压缩  |
+| 服务器推送 | 不支持  | 不支持  | 支持  |
 :::
 
 ### 数字证书

src/guide/concepts/network/2-tcp-udp.md

@@ -0,0 +1,70 @@
+---
+order: 2
+title: "TCP/UDP"
+---
+
+### TCP
+
+传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议。
+
+#### TCP 头部结构
+
+![tcp 头部](/assets/image/article/network/tcp.png)
+
+| TCP头部字段 | 描述 |
+| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 源端口 | 发送方的端口号，范围(0~65535) |
+| 目标端口 | 接收方的端口号，范围(0~65535) |
+| 序列号 | 如果TCP数据过大（大于IP数据包的允许程度），则需要进行分段。这个序列号记录每个数据包的序列号，使接收端可以重新组合TCP数据。序列号字段的值是本报文段发送的数据的第一个字节的序列号。简称为`seq` |
+| 确认号 | 为了确认接收端确实收到了发送端发送的数据包数据，当发送端收到这个确认码时，就可以确定之前传递的数据包已经被正确接收。这个确认号是期望收到对方下一个报文段的数据的第一个字节的序列号。简称`ack` |
+| 头部长度 | 表示TCP头部的长度，范围(0~15)，单位32位，例如值为5时，表示头部长度是20字节（160位），如果选项字段为空，则TCP头部长度为20字节，即值为5 |
+| URG | `URG=1`表示存在紧急数据，紧急数据的最后一个字节由紧急数据指针指出，一般使用较少 |
+| ACK | `ACK=1`表示确认号字段中的值是有效的，为0表示无效 |
+| PSH | `URG=1`表示紧急指针字段有效，代表该数据包为紧急数据包。它告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的数据） |
+| RST | `RSP=1`表示重建连接，如果接收到RST位时，通常发生了某些错误 |
+| SYN | `SYN=1`表示这是一个连接请求或连接接受报文，一般用于握手阶段 |
+| FIN | `FIN=1`表示此报文段的发送端的数据已发送完毕，并要求释放运输连接 |
+| 接收窗口 | 用于流量控制，指示接收方愿意接收的字节数量，范围`0~65535`字节 |
+| 校验和 | 校验和覆盖了整个TCP报文段，即TCP头部和TCP数据，这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证 |
+| 紧急数据指针 | 当`URG=1`时有效，是一个正的偏移量，和序列号中的值相加表示紧急数据最后一个字节的序列号 |
+| 选项 | 用于发送方和接收方协商最大报文长度（MSS）时（只存在于SYN报文）或在高速网络环境下用作窗口调节因子时使用，还可以存放时间戳数据 |
+
+#### TCP 状态机
+
+![TCP Stateful](/assets/image/article/network/tcp_state.png)
+
+#### TCP 三次握手
+
+![TCP Connection](/assets/image/article/network/tcp-connect.png)
+
+::: tip 三次握手过程
+1. 客户端发送`SYN=1`，并指明客户端的初始序列号`ISN`，即`x`.
+2. 服务端发送自己的`SYN`段作为应答，同样指明自己的`ISN` 即 `y`。为了确认客户端的`SYN`，将`x+1`作为`ACK`数值。这样，每发送一个`SYN`，序列号就会加1. 如果有丢失的情况，则会重传。
+3. 为了确认服务器端的`SYN`，客户端将`y+1`作为返回的`ACK`数值。
+
+:::
+
+::: tip TCP 四次挥手
+1. 客户端发送`FIN=1`，并包含一个自己当前的序列号`x+2`。 同时还包含一个`ACK=y+1`表示确认对方最近一次发过来的数据。 
+2. 服务端将`x+2`值加1作为`ACK`序号值，表明收到了上一个包。这时上层的应用程序会被告知另一端发起了关闭操作，通常这将引起应用程序发起自己的关闭操作。 
+3. 服务端发起自己的`FIN=1`，`seq=y+1` 。
+4. 客户端确认, 向服务器发送 `ACK=y+2` 。
+:::
+
+::: warning 为什么要三次握手？作用是什么？
+
+::: details
+TCP 建立连接的过程就是同步序列号的过程，SYN (Synchronize Sequence Numbers)就是同步序列号。因此，三次握手的目的就是使客户端(Client)和服务端(Service)获取到对方的序列号。
+:::
+
+::: warning 为什么要四次挥手？作用是什么？
+
+::: details
+之所以需要四次挥手，是因为 tcp 是**全双工**协议，即客户端和服务端都可以主动发送消息，因此需要两端分别在传输完成后发送断开连接的指令，需要分别发送 `FIN=1` 指令断开，通过 `ACK` 判断是否发送成功。
+:::
+
+::: danger 如果连接时 SYN 超时会发生什么？
+
+::: details
+假如客户端发送 `SYN` 指令，在服务器返回 `SYN` 指令之前掉线了，服务器会尝试重发 `SYN-ACK` 指令，linux 下默认重试 5 次，间隔时间从 1s 开始翻倍增长，即 `1s, 2s, 4s, 8s, 16s`, 因此超时时间为 `1s + 2s + 4s+ 8s+ 16s + 32s = 63s`。在超时之后 TCP 才会断开连接。
+:::