一、TCP协议段格式

• 16位源端口： 发送方主机的应用程序的端口号
• 16位目的端口： 目的主机的应用程序的端口号
• 32位TCP序号： 表示本报文段所发送数据的第一个字节的编号。
• 32位TCP确认序号： 接收方期望收到发送方下一个报文段的第一个字节数据的编号。
• 4位首部长度： 指的是数据段中的“数据”部分起始处距TCP报文段起始处的字节偏移量。
• 6位保留字段： 为TCP将来的发展预留空间，目前必须全部为0.
• 6位标志位： 共有6个标志位，每个标志位占一个bit。
• 16位窗口大小： 表示发送该TCP报文的接收窗口还可以接受多少字节的数据量。该字段用于流量控制。
• 16位检验和字段： 用于确认传输的数据有无损坏。发送端基于数据内容校验生成一个数值，接收端根据接受的数据校验生成一个值。两个值相同代表数据有效，反之无效，丢弃该数据包。校验和根据 伪报头 + TCP头 + TCP数据 三部分进行计算。
• 16位紧急指针字段： 仅当标志位字段的URG标志位为1时才有意义。指出有效载荷中为紧急数据的字节数。当所有紧急数据处理完后，TCP就会告诉应用程序恢复到正常操作。即使接收方窗口大小为0，也可以发送紧急数据，因为紧急数据无须缓存。
• 选项字段： 长度不定，但长度必须是32bits的整数倍。内容可变，因此必须使用首部长度来区分选项的具体长度。

1.1 32位序号与确认号

1.1.1 32位序号

序号占用 4 字节，即 32 位。也就是说一共有 4 294 967 296 个序号。TCP 协议中的序号，指的是报文段序号。

• 初始序号 ISN
  当新连接建立的时候，第一个字节数据的序号称为 ISN(Initial Sequence Number)，即初始序号。**ISN 一开始并不一定就是 1。**在 RFC (规定网络协议的文档)中规定，ISN 的分配是根据时间来的。当操作系统初始化的时候，有一个全局变量假设为 g_number 被初始化为 1（或 0），然后每隔 4us 加 1. 当 g_number 达到最大值的时候又绕回到 0.当新连接建立时，就把 g_number 的值赋值给 ISN.

在 BSD 系统中，这段代码实现时并未遵守协议，它将 g_number 初始化为 1，每 8us 加 1，也就是说，每隔 1 秒增加 125000，约 9.5 小时后 g_number 又绕回到了 0.

初始序号是非常非常重要的概念，它告诉对端，第一个报文段是谁！而三次握手的目的，就是为了确认初始序号。

• 字节序号
  TCP 连接中，为传送的字节流（数据）中的每一个字节按顺序编号。也就是说，在一次 TCP 连接建立的开始，到 TCP 连接的断开，你要传输的所有数据的每一个字节都要编号。这个序号称为字节序号。

• 报文段序号
  所以 报文段序号 = 初始序号 + 字节序号（其中字节序号）
  比如 初始序号为 1000，而要发送数据是缓冲区中的1~2000数据，那么报文段的序号为1000，它携带了2000字节的数据，就表示这2000个字节的数据的字节序号的范围是[1000, 3000]，该报文段携带的第一个字节序是1000，最后一个字节序号序号是3000。

再来一个例子：
如果一个 TCP 报文段的序号为 301，它携带了 100 字节的数据，就表示这 100 个字节的数据的字节序号范围是 [301, 400]，该报文段携带的第一个字节序号是 301，最后一个字节序号是 400.

序列号还有一个作用：
由于网络，我们发送的数据不一定会按顺序到达接收方，因此接收方拿到数据后，会在接受缓冲区中通过序列号对数据进行排序，保持数据不是紊乱的。

而且可能由于丢包的原因，发送方没有及时收到来自接收方的应答，发送方会再次发送同意的报文给接收方，造成接收方收到多个同样报文，而接收方通过判断序列号可以做到去重的效果。

1.1.2 确认号

假设客服端给服务端发送了一个tcp报文，其中报文段的序号为301，并且携带了100字节的数据。那么作为服务器我们要给客户端做出应答，此时服务器的应答报文中的确认号就是401。

表示服务器已经收到了字节序号为 [0, 400] 的数据，现在期望你发送字节序号为 401 以及以后的数据。

确认号表示：
确认应答号是接收方期望从发送方接收到的下一个报文段的序号。它实质上是接收方告诉发送方：“我已经成功接收到了哪个序号之前的所有数据，请从这个序号开始发送后续的数据。”

1.2 4位首部长度

4位首部占4个比特位，所以范围是[0, 15]，4位首部的单位是4字节，所以tcp报文的报头最大有60字节，其中前20字节是固定的，后40字节是可选项（可有可无）。

因此tcp报文的报头范围是[15, 60] ，单位是 1 字节。

1.3 6位标志位

• URG: 紧急指针是否有效
• ACK: 确认号是否有效
• PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
• RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
• SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
• FIN: 通知对方, 本端要关闭了

1.4 16位窗口大小

窗口大小（Window Size）是 TCP（传输控制协议）数据包头部中的一个重要字段，用于指定接收方的缓冲区大小。它告知发送方在不需要等待确认的情况下，可以发送多少数据。

二、确认应答(ACK)机制

• 当客户端 发送报文 到 服务器时是要经过网络的，因此报文可能会因为各种原因造成数据没有传送到服务端，而服务端为了告诉客户端它已经接受到了数据，所以服务端会发送应当报文给客户端。

需要注意的是即使是应答报文也会存在丢包的情况。 假设主机A同时发送 1~1000数据和1001~2000给B,但是主机B给A的1~1000应答报文出现了丢包，主机B应答了 1001~2000数据，此时主机A也认为B收到了1~1000的数据，因为应答了1001~2000数据的报文的确认号是2001。

上面我们说到确认号表示：“我已经成功接收到了哪个序号之前的所有数据，请从这个序号开始发送后续的数据。”

三、超时重传机制

超时重传就是发送数据发经过一段时间还没有收到接收方的应答就会重新发送该报文。

情况一：

• 主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B;
• 如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发;
  

---

情况二：

• 主机A未收到B发来的确认应答, 也可能是因为ACK丢失了;
  
  因此主机B会收到很多重复数据. 那么TCP协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉. , 就可以很容易做到去重的效果. 这时候我们可以利用前面提到的序列号。

那么, 如果超时的时间如何确定?

• 最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”.
• 但是这个时间的长短, 随着网络环境的不同, 是有差异的.
• 如果超时时间设的太长, 会影响整体的重传效率;
• 如果超时时间设的太短, 有可能会频繁发送重复的包;

TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间.

• Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍.
• 如果重发一次之后, 仍然得不到应答, 等待 2*500ms 后再进行重传.
• 如果仍然得不到应答, 等待 4*500ms 进行重传. 依次类推, 以指数形式递增.
• 累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接.

---

四、连接管理机制

在正常情况下, TCP要经过三次握手建立连接, 四次挥手断开连接

4.1 三次握手(连接)

服务器和客户端转台变化:
[CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态, 等待客户端连接;(同步报文段), 就将该连接放入内核等待队列中。
[CLOSED -> SYN_SENT] 客户端调用connect, 发送SYN报文给服务端;
[LISTEN -> SYN_RCVD] 服务器一旦监听到连接请求（接收到来自客户端的SYN） , 并向客户端发送SYN确认报文。
[SYN_SENT -> ESTABLISHED] 客户端接受到来自服务端的SYN+ACK并且发送ACK给服务器后，connect调用成功, 则进入ESTABLISHED状态, 开始读写数据;
[SYN_RCVD -> ESTABLISHED] 服务端一旦收到客户端的确认报文, 就进入ESTABLISHED状态, 可以进行读写数据了。

有的时候把这个建立连接的过程叫做“四次握手”，这是因为这种说法把第二次握手 ACK+SYN 拆分成了两次握手，实际上都是一样的。

还有一个问题，若第三次握手的报文在传输过程中丢失了怎么办？？那这不就造成了客户端认为建立了连接，而实际上服务端没有建立。

但这没有关系，就算ACK报文段丢失了，那server不会认为连接建立成功，此时如果client给server发送消息，则server会感觉很奇怪，既然连接不建立成功，你还给我发消息，那就说明我们双方产生了认为连接建立不一致的情况，那server就会给client发送复位报文段，请求重新三次握手，重新建立连接，因为我们现在连接的建立是不一致的，client认为连接建立成功，但server不认为成功。

---

或者还有另一种情况，server发送的SYN报文段超时没有确认应答，则server就会进行超时重传，当client收到重复的捎带应答报文段时，client就会意识到自己给server发送的确认应答报文段可能丢失了，此时client就会重发ACK报文段。

listen的第二个参数

int listen(int sockfd, int backlog);

第二个参数是设置全连接队列的长度，全连接队列 = backlog + 1.

Linux内核协议栈为一个tcp连接管理使用两个队列:

1. 半链接队列（用来保存处于SYN_SENT和SYN_RECV状态的请求）
2. 全连接队列（accpetd队列）（用来保存处于established状态，但是应用层没有调用accept取走的请求）

而全连接队列的长度会受到 listen 第二个参数的影响，全连接队列满了的时候, 就无法继续让当前连接的状态进入 established 状态了.

不知道各位发现没有，我们建立连接的过程其实和accept并没有关系。accept() 不需要参与三次握手的过程。三次握手是 TCP 协议在内核层面完成的，accept 只是在应用层面从全连接队列中取出一个已经建立的连接，并返回一个新的套接字。也就是说，连接已经在内核中建立好了，accept() 只是一个查询和返回的过程，并不影响三次握手的逻辑

因此建立好连接会被放在全连接队列，若全连接队列满了就会造成连接丢失的问题，所以我们要合理控制全连接队列的长度，和应用层要及时accept。

4.2 四次挥手(断开连接)

服务器和客户端转台变化:

[ESTABLISHED -> FIN_WAIT_1] 客户端主动调用close时, 向服务器发送结束报文段FIN, 同时进入
FIN_WAIT_1;
[ESTABLISHED -> CLOSE_WAIT] 当客户端主动关闭连接(调用close), 服务器会收到结束报文段, 服务器返回确认报文段并进入CLOSE_WAIT;
[FIN_WAIT_1 -> FIN_WAIT_2] 客户端收到服务器对结束报文段的确认, 则进入FIN_WAIT_2, 开始等待服务器的结束报文段;
[CLOSE_WAIT -> LAST_ACK] 进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据); 当服务器真正调用close关闭连接时, 会向客户端发送FIN, 此时服务器进入LAST_ACK状态, 等待最后一个ACK到来(这个ACK是客户端确认收到了FIN)
[FIN_WAIT_2 -> TIME_WAIT] 客户端收到服务器发来的结束报文段, 进入TIME_WAIT, 并发出LAST_ACK;
[LAST_ACK -> CLOSED] 服务器收到了客户端对FIN的ACK, 彻底关闭连接.
[TIME_WAIT -> CLOSED] 客户端要等待一个2MSL(Max Segment Life, 报文最大生存时间)的时间, 才会进入CLOSED状态.

为什么是四次挥手不是三次挥手呢？？？
因为当客户端在进入到TIME_WAIT状态后并不是关闭所有的缓冲区，而是关闭发送缓冲区，而接受缓冲区是打开的，因为在关闭前，网络中可能仍然存在传递中的数据，或者服务端要发送数据给客户端，所以我们不能把服务端的FIN和ACK整合成一个报文发送。

TIME_WAIT状态

• TCP协议规定,主动关闭连接的一方要处于TIME_ WAIT状态,等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态.
• MSL在RFC1122中规定为两分钟,但是各操作系统的实现不同, 在Centos7上默认配置的值是60s;
• 可以通过 cat /proc/sys/net/ipv4/tcp_fin_timeout 查看msl的值。

为什么是TIME_WAIT的时间是2MSL?

• MSL是TCP报文的最大生存时间, 因此TIME_WAIT持续存在2MSL的话就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启, 可能会收到来自上一个进程的迟到的数据, 但是这种数据很可能是错误的);同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失, 那么服务器会再重发一个FIN. 这时虽然客户端的进程不在了, 但是TCP连接还在, 仍然可以重发LAST_ACK);

若我们使用Ctrl-C终止了server, 所以server是主动关闭连接的一方, 在TIME_WAIT期间仍然不能再次监听同样的server端口，而客户端断开就没有这种现象？

• 因为客户端的端口是随机分配的，而服务端的端口通常是固定的，当我们再次连接客户端会随机分配一个端口，而重新启动服务端这时服务器并没有真正的关闭还在TIME_WAIT的状态中。
• 怎么解决服务器的这种现象呢?只需要设置sockfd选项为重用本地地址SO_REUSEADDR，即使服务器(主动断开连接)的sockfd对应的连接结构体处于TIME_WAIT状态，与sockfd绑定的socket地址(struct sockaddr_in local)也可以立即被重用，这样就可以实现服务器立即重启依旧能bind原来的端口号了。
  

五、控制

5.1 流量控制

接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送,就会造成丢包, 继而引起丢包重传等等一系列连锁反应. 因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control);

• 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端;
• 窗口大小字段越大, 说明网络的吞吐量越高;
• 接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;
• 发送端接受到这个窗口之后, 就会减慢自己的发送速度;
• 如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端.

接收端如何把窗口大小告诉发送端呢? 回忆我们的TCP首部中, 有一个16位窗口字段, 就是存放了窗口大小信息; 那么问题来了, 16位数字最大表示65535, 那么TCP窗口最大就是65535字节么?
实际上, TCP首部40字节选项中还包含了一个窗口扩大因子M, 实际窗口大小是 窗口字段的值左移 M 位;

5.2 滑动窗口

早期的网络通信中，通信双方不会考虑网络的 拥挤情况直接发送数据。由于大家不知道网络拥塞状况，同时发送数据，导致中间节点阻塞掉包， 谁也发不了数据，所以就有了滑动窗口机制来解决此问题。滑动窗口协议是用来改善吞吐量的一种 技术，即容许发送方在接收任何应答之前传送附加的包。接收方告诉发送方在某一时刻能送多少包 （称窗口尺寸）。

1. 已经发送同时被ACK的数据(这部分数据可以被新数据覆盖)，
2. 已经发送但没有被ACK的数据(这部分数据不能被新数据覆盖)，
3. 尚未被发送但可发送的数据(刚刚从应用层缓冲区中拷贝下来的数据)，
4. 未发送且不可发送(其实开辟空间时，有初始化的数据)
   

当数据已发送已确认，那么窗口最左边就会向右移，当有数据成了可以发/已经发但未确认的，那么窗口就会向右移动。

情况一: 数据包已经抵达, ACK被丢了.

这种情况下, 部分ACK丢了并不要紧, 因为可以通过后续的ACK进行确认。

情况二: 数据包就直接丢了
滑动窗口保证了线性的连续的向后更新，不会出现跳跃的情况。表示的确认序号x之前的报文都收到了，不会出现报文遗漏。

• 当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 “我想要的是 1001” 一样;
• 如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送;
• 这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中

这种机制被称为 “高速重发控制”(也叫 “快重传”).

缓冲区是有大小的，那么滑动窗口有可能越界吗??
不会，实际上tcp采用了类似环状算法。类似循环队列
已确认已应答的数据我们是可以覆盖的，当我们的缓冲区已经到尽头的时候，这时候缓冲区中肯定存在哪些已确认已应答的数据，而我们只要继续在缓冲区开始覆盖数据即可。

5.3 拥塞控制

虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题. 因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据,是很有可能引起雪上加霜的.

TCP引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;

• 此处引入一个概念程为拥塞窗口
• 发送开始的时候, 定义拥塞窗口大小为1;
• 每次收到一个ACK应答, 拥塞窗口加1;
• 每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口;

像上面这样的拥塞窗口增长速度, 是指数级别的. “慢启动” 只是指初使时慢, 但是增长速度非常快.

• 为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍.
• 此处引入一个叫做慢启动的阈值，当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长
  
  当TCP开始启动的时候, 慢启动阈值等于窗口最大值;
  在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1;

少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;
当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;
拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案.

因此我们再次认识一下滑动窗口的大小:
滑动窗口=min（窗口大小，拥塞窗口,有效数据）。
窗口大小：对方主机的接收能力。
拥塞窗口：考虑的是动态的、网络的接受能力。
有效数据 : 发送缓冲区的有效数据

所以我们网络中有三大窗口：
滑动窗口
接收窗口
拥塞窗口：主机判断网络健康程度的指标（发送数据超过拥塞窗口，会引发网络拥塞，否则就不会。而网络是动态的，拥塞窗口本身肯定不能是静态的！）

5.4 延迟应答

如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口(接受缓冲区)可能比较小.

• 假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;
• 但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;
• 在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;
• 如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;

一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;

那么所有的包都可以延迟应答么? 肯定也不是;

• 数量限制: 每隔N个包就应答一次;
• 时间限制: 超过最大延迟时间就应答一次;

具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms;

5.5 捎带应答

在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 “一发一收” 的.就是应答的同时捎带其它数据不单单是应答。

比如在三次握手中，原本四次握手也可以，但是捎带应答简化了这一过程。

六、其它问题

6.1 面向字节流

当创建一个 TCP 的 socket 时，同时在内核中会创建一个发送缓冲区和一个接收缓冲区。

• 调用 write 函数就可以将数据写入发送缓冲区中，但是如果发送缓冲区已满，write 函数会阻塞，直到有足够的空间可以写入数据。发送缓冲区当中的数据会由 TCP 自行进行发送，但是发送的字节流的大小会根据窗口大小、拥塞控制、流量控制等因素来动态调整。如果发送的字节数太长，TCP 会将其拆分成多个数据包发出。如果发送的字节数太短，TCP 可能会先将其留在发送缓冲区当中，等到合适的时机再进行发送。
• 接收数据的时候，数据也是从网卡驱动程序到达内核的接收缓冲区，可以通过调用 read 函数来读取接收缓冲区当中的数据。但是如果接收缓冲区为空，read 函数会阻塞，直到有数据到达。接收缓冲区当中的数据也是由 TCP 自行进行接收，但是接收的字节流的大小会根据窗口大小、确认机制等因素来动态调整。而调用 read 函数读取接收缓冲区中的数据时，也可以按任意字节数进行读取。

由于缓冲区的存在，TCP 程序的读和写不需要一一匹配，例如：

• 写 100 个字节数据时，可以调用一次 write 写 100 字节，也可以调用 100 次 write，每次写一个字节。
• 读 100 个字节数据时，也完全不需要考虑写的时候是怎么写的，既可以一次 read100 个字节，也可以一次 read 一个字节，重复 100 次。

6.2 粘包问题

• 首先要明确, 粘包问题中的 “包” , 是指的应用层的数据包.
• 在TCP的协议头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段.
• 站在传输层的角度, TCP是一个一个报文过来的. 按照序号排好序放在缓冲区中.
• 站在应用层的角度, 看到的只是一串连续的字节数据.
• 那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包.

那么如何避免粘包问题呢? 归根结底就是一句话, 明确两个包之间的边界.

• 对于定长的包, 保证每次都按固定大小读取即可; 例如上面的Request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可;
• 对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置;
• 对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可)

对于UDP协议来说, 是否也存在 “粘包问题” 呢?

• 对于UDP, 如果还没有上层交付数据, UDP的报文长度仍然在. 同时, UDP是一个一个把数据交付给应用层. 就有很明确的数据边界.
• 站在应用层的站在应用层的角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收. 不会出现"半个"的情况.

6.3 TCP异常情况

• 进程终止: 进程终止会释放文件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别.
• 机器重启: 和进程终止的情况相同.
• 机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行reset. 即使没有写入操作, TCP , 会定期询问对方是否还在 自己也内置了一个保活定时器 . 如果对方不在, 也会把连接释放.

另外, 应用层的某些协议, 也有一些这样的检测机制. 例如HTTP长连接中, 也会定期检测对方的状态. 例如QQ, 在QQ断线之后, 也会定期尝试重新连接.

6.4 socket和文件之间的关系