layout: post
title: 八股总结（二）计算机网络与网络编程
description: 八股总结（二）计算机网络与网络编程
tag: 八股总结

文章目录

• 计算机网络
• • 网络模型
  • • 网络体系结构
    • 在浏览器输入一个网址后回车，背后都发生了什么？
  • 数据链路层
  • • 地址解析ARP（address resolution protocol）协议
  • 网络层
  • • 网际控制报文协议ICMP（internet control message protocol）
  • 传输层
  • • TCP协议
    • • 什么是TCP协议？
      • 什么是TCP粘包/拆包？发生的原因？解决方法？
      • TCP和UDP的区别
      • TCP和UDP的应用场景？
      • 为什么TCP有「首部⻓度」字段，UDP没有？
      • TCP报文结构
      • TCP建立连接为什么是3次握手，而不是2次或者4次？
      • SYN攻击（DDOS攻击）原理及避免方法
      • TCP连接4挥手断开连接
      • TCP重传机制
      • TCP滑动窗口
      • 流量控制
      • 拥塞控制
    • UDP协议
  • 应用层
  • • HTTP
    • • HTTP状态码
      • GET和POST的区别？
      • HTTP和HTTPS的区别？
      • HTTPS解决了HTTP哪些问题，是怎么解决的？
      • SLL/TLS协议基本流程
      • HTTP/1.1、HTTP/2、HTTP/3演变
    • 域名解析协议（DNS，Domain Name System）
    • • 为什么域名解析用UDP协议？
    • 动态主机配置协议（DHCP，Dynamic Host Configuration Protocol）
• Linux网络编程
• • TCP的socket编程

计算机网络

网络模型

网络体系结构

OSI七层模型是法律上规定的国际标准，但TCP/IP体系占据了市场，是实际上的国际标准，为了方便理解，由将TCP/IP四层的结构中的网络接口层分为了物理层和数据链路层。

• 物理层的数据为比特流，数据链路层为帧，网络层为包，传输层为数据段。
• 各层常用的网络协议有哪些？
  • 数据链路层：ARP（地址解析协议）
  • 网络层：IP协议、ICMP（网际控制报文协议）、VPN、内部网关协议（如路由信息协议RIP）、外部网关协议（如边界网关协议BGP）
  • 传输层：TCP（传输控制协议）、UDP（用户数据报协议）
  • 应用层：DNS（域名解析），FTP（文件传输），DHCP（动态主机配置协议），HTTP（超文本传输协议）

网络协议栈数据报文发送与接收过程中的变化：

在浏览器输入一个网址后回车，背后都发生了什么？

1. 查看浏览器缓存，如果没有
2. 向DNS服务器发送DNS请求（采用的是UDP协议），查询本地DNS服务器。
3. 如果本地DNS查不到，就从根域名服务器，递归的查询每一级域名服务器，直到查到为止。
4. 有了DNS解析结果，我们就有了服务器的ip地址，以及默认的端口号了，http默认端口号是80，https默认端口号443。

数据链路层

通俗来讲，数据链路层完成的是从目的主机所在路由器（目的MAC地址）到本地路由器（源MAC地址）的连接。

地址解析ARP（address resolution protocol）协议

ARP地址解析协议只能在单个数据链路段中使用，用于将IP地址解析为对应的MAC地址。

网络层

通俗来讲，网络层完成目的主机和本地主机之间的连接。

网络层最常用的就是IP协议（Internet protocol），将传输层的报文作为数据部分再加上IP包头组装成IP报文，如果IP报文超过MTU（以太网中一般为1500字节）就会再次进行分片，得到一个即将发送到网络的IP报文。

IP 地址分成两种意义：
⼀个是⽹络号，负责标识该 IP 地址是属于哪个⼦⽹的；
⼀个是主机号，负责标识同⼀⼦⽹下的不同主机。

网际控制报文协议ICMP（internet control message protocol）

为了有效转发IP数据报和提高交付成功的机会，网际层使用了网际控制报文协议ICMP，使得主机和路由器可以使用ICMP来发送差错报告报文 和 询问报文，ICMP报文被封装在IP数据报中发送。
ICMP差错报文分为以下5种：

传输层

网络层已经解决了主机与主机之间的通信，而传输层要解决的是两个主机各自进程间进行通信的问题。

TCP协议

什么是TCP协议？

TCP是面向连接的、可靠的、基于字节流的传输层通信协议。

• 面向连接：一定是一对一才能连接，不像UDP协议可以一台主机同时向多个主机发送消息。也就是说TCP只能一对一，不能像UDP那样一对多。
• 可靠的：无论网络链路中出现怎样的链路变化，TCP都可以保证一个报文一定能够到达接收端；
• 字节流：消息是无边界的，所以无论我们的消息有多大都可以进行传输，而且消息是有序的，当前一个没有收到的时候，即使它先收到了后边的字节，那么也不能扔给应用层去处理，同时对重复的报文会自动丢弃。

什么是TCP粘包/拆包？发生的原因？解决方法？

一个完整的业务可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这个就是TCP的拆包和粘包问题。

原因
1、应用程序写入数据的字节大小大于套接字发送缓冲区的大小.

2、进行MSS大小的TCP分段。( MSS=TCP报文段长度-TCP首部长度)

3、以太网的payload大于MTU进行IP分片。（ MTU指：一种通信协议的某一层上面所能通过的最大数据包大小。）

解决方案：
1、增加消息长度字段。

2、在包尾部增加回车或者空格符等特殊字符进行分割

3、将消息分为消息头和消息尾

4、使用其它复杂的协议，如RTMP协议等。

TCP和UDP的区别

• 连接：TCP是面向连接的传输层协议，传输数据前需要先建立连接，而UDP是不需要连接，即刻传输数据。
• 服务对象：TCP是一对一两点服务，UDP支持一对一、一对多和多对多
• 可靠性：TCP是可靠交付数据，数据可以无差错、不丢失、不重复、按需到达；UDP是尽最大努力交付，不保证可靠交付数据
• 拥塞控制、流量控制：TCP有拥塞控制和流量控制机制，保证数据传输的安全性，UDP则没有，即便是网络非常拥堵，也不会影响UDP的发送速率。
• 首部开销：TCP首部长，而UDP首部只有8个字节
• 传输方式：TCP是流式传输，没有边界，但是保证顺序和可靠；UDP是一个包一个包的发送，是有边界的，但是可能会丢包和乱序。

TCP和UDP的应用场景？

由于TCP是面向连接的，能够保证数据的可靠性交付，因此经常被用于FTP文件传输，HTTP、HTTPS

由于UDP是面向无连接的，它可以随时发送数据，加上UDP本身的处理既简单又高效，因此经常用于包总量较少的通信，如DNS、SNMP等，视频，音频等多媒体通信，广播通信。

为什么TCP有「首部⻓度」字段，UDP没有？

原因是 TCP 有可变⻓的「选项」字段，⽽ UDP 头部⻓度则是不会变化的，⽆需多⼀个字段去记录 UDP 的⾸部⻓度。

TCP报文结构

1. 端口号：TCP是进程与进程间的通信，因此，头部两端是16位的源端口号和16位的目的端口号

2. 序列号（SEQ）：在建立连接时由计算机生成的随机数作为其初始值，通过SYN包传递给接收端主机，每发送一次数据，就累加一次该数据字节数的大小，用来解决网络包乱序问题。

3. 确认应答号（ACK）：指下一次期望收到数据的序列号，发送端收到这个应答以后可以认为在这个序号以前的数据都已经被正常接收，用来解决不丢包的问题。

4. 控制位：ACK：该位为 1 时，「确认应答」的字段变为有效，TCP 规定除了最初建⽴连接时的 SYN 包之外该位必须设置为 1。
   RST：该位为 1 时，表示 TCP 连接中出现异常必须强制断开连接。
   SYN：该位为 1 时，表示希望建⽴连接，并在其「序列号」的字段进⾏序列号初始值的设定。
   FIN：该位为 1 时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双⽅的主机之间就可以相互交换 FIN 位为 1 的 TCP 段。

5. 窗口大小：用于拥塞控制

6. 校验和：差错控制

7. 紧急指针：仅当前面的 URG 控制位为 1 时才有意义。它指出本数据段中为紧急数据的字节数，占 16 位。当所有紧急数据处理完后，TCP 就会告诉应用程序恢复到正常操作。即使当前窗口大小为 0，也是可以发送紧急数据的，因为紧急数据无须缓存。

8. 选项（Option）：长度不定，但长度必须是 32bits 的整数倍。

9. 数据

TCP建立连接为什么是3次握手，而不是2次或者4次？

• 三次握手才可以阻止重复历史连接的初始化（首要原因）
• 三次握手才可以同步双方的初始序列号
• 三次我说才可以避免资源浪费

客户端连续发送多次SYN建立连接的报文，在网络拥堵情况下，一次旧的SYN报文比新的SYN报文到达了服务端，那么此时服务端就会返回一个SYN + ACK报文给客户端，客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列化过期或者超时），那么客户端就会发送RST报文给服务端，表示终止这一次连接。

如果是两次握手，就不足以判断当前连接是否为历史连接。

SYN攻击（DDOS攻击）原理及避免方法

我们都知道 TCP 连接建⽴是需要三次握⼿，假设攻击者短时间伪造不同 IP 地址的 SYN 报⽂，服务端每接收到⼀个 SYN 报⽂，就进⼊ SYN_RCVD 状态，但服务端发送出去的 ACK + SYN 报⽂，⽆法得到未知 IP 主机的 ACK 应答，久⽽久之就会占满服务端的 SYN 接收队列（未连接队列），使得服务器不能为正常⽤户服务。

TCP连接4挥手断开连接

• 客户端打算关闭连接，此时会发送⼀个 TCP ⾸部 FIN 标志位被置为 1 的报⽂，也即 FIN 报⽂，之后客户端进⼊ FIN_WAIT_1 状态。
• 服务端收到该报⽂后，就向客户端发送 ACK 应答报⽂，接着服务端进⼊ CLOSED_WAIT 状态。
• 客户端收到服务端的 ACK 应答报⽂后，之后进⼊FIN_WAIT_2 状态。
• 等待服务端处理完数据后，也向客户端发送 FIN 报⽂，之后服务端进⼊ LAST_ACK 状态。
• 客户端收到服务端的 FIN 报⽂后，回⼀个 ACK 应答报⽂，之后进⼊ TIME_WAIT 状态
• 服务器收到了 ACK 应答报⽂后，就进⼊了 CLOSED 状态，⾄此服务端已经完成连接的关闭。
• 客户端在经过 2MSL ⼀段时间后，⾃动进⼊ CLOSED 状态，⾄此客户端也完成连接的关闭。

MSL 是 Maximum Segment Lifetime，报⽂最⼤⽣存时间

TCP重传机制

TCP 针对数据包丢失的情况，会⽤重传机制解决。常见的重传机制如下：

1. 超时重传：是在发送数据时，设定⼀个定时器，当超过指定的时间后，没有收到对⽅的 ACK 确认应答报⽂，就会重发该数据，也就是我们常说的超时重传。（发送数据包丢失和对方ACK数据包丢失都会触发超时重传）

RTO（Retransmission Timeout 超时重传时间）根据RTT（Round-Trip Time ，往返时延/）确定。

2. 快速重传
   快速重传的⼯作⽅式是当收到三个相同的 ACK 报⽂时，会在定时器过期之前，重传丢失的报⽂段。
   
   快速重传机制只解决了⼀个问题，就是超时时间的问题，但是它依然⾯临着另外⼀个问题。就是重传的时候，是重
   传之前的⼀个，还是重传所有的问题。
   ⽐如对于上⾯的例⼦，是重传 Seq2 呢？还是重传 Seq2、Seq3、Seq4、Seq5 呢？因为发送端并不清楚这连续的
   三个 Ack 2 是谁传回来的。

3. SACK （ Selective Acknowledgment 选择性确认）重传
   这种⽅式需要在 TCP 头部「选项」字段⾥加⼀个 SACK 的东⻄，它可以将缓存的地图发送给发送⽅，这样发送⽅就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。
   如下图，发送⽅收到了三次同样的 ACK 确认报⽂，于是就会触发快速重发机制，通过 SACK 信息发现只有200~299 这段数据丢失，则重发时，就只选择了这个 TCP 段进⾏重复。如果要⽀持 SACK ，必须双⽅都要⽀持。在 Linux 下，可以通过 net.ipv4.tcp_sack 参数打开这个功能（Linux2.4 后默认打开）。

4. Duplicate SACK ⼜称 D-SACK ，其主要使⽤了 SACK 来告诉「发送⽅」有哪些数据被重复接收了。
例子1：

• 「接收⽅」发给「发送⽅」的两个 ACK 确认应答都丢失了，所以发送⽅超时后，᯿传第⼀个数据包（3000 ~
  3499）
• 于是「接收⽅」发现数据是重复收到的，于是回了⼀个 SACK = 3000~3500，告诉「发送⽅」 3000~3500 的数据早已被接收了，因为 ACK 都到了 4000 了，已经意味着 4000 之前的所有数据都已收到，所以这个 SACK就代表着 D-SACK 。
• 这样「发送⽅」就知道了，数据没有丢，是「接收⽅」的 ACK 确认报⽂丢了。

例子2：

• 数据包（1000~1499） 被⽹络延迟了，导致「发送⽅」没有收到 Ack 1500 的确认报⽂。
• ⽽后⾯报⽂到达的三个相同的 ACK 确认报⽂，就触发了快速重传机制，但是在重传后，被延迟的数据包（1000~1499）⼜到了「接收⽅」；
• 所以「接收⽅」回了⼀个 SACK=1000~1500，因为 ACK 已经到了 3000，所以这个 SACK 是 D-SACK，表示收到了重复的包。这样发送⽅就知道快速重传触发的原因不是发出去的包丢了，也不是因为回应的 ACK 包丢了，⽽是因为⽹络延迟了。

可见使用D-SACK的好处是：

• 可以让发送方知道，是发出的包丢了，还是接收方回应的ACK包丢了；
• 可以知道是不是发送包的数据包被网络延迟了

在 Linux 下可以通过 net.ipv4.tcp_dsack 参数开启/关闭这个功能（Linux 2.4 后默认打开）。

TCP滑动窗口

#1 是已发送并收到 ACK确认的数据：1~31 字节
#2 是已发送但未收到 ACK确认的数据：32~45 字节
#3 是未发送但总⼤⼩在接收⽅处理范围内（接收⽅还有空间）：46~51字节
#4 是未发送但总⼤⼩超过接收⽅处理范围（接收⽅没有空间）：52字节以后

TCP 滑动窗⼝⽅案使⽤三个指针来跟踪在四个传输类别中的每⼀个类别中的字节。其中两个指针是绝对指针（指特
定的序列号），⼀个是相对指针（需要做偏移）。

接收部分如上图所示，其中三个接收部分，使⽤两个指针进⾏划分:
RCV.WND ：表示接收窗⼝的⼤⼩，它会通告给发送⽅。
RCV.NXT ：是⼀个指针，它指向期望从发送⽅发送来的下⼀个数据字节的序列号，也就是 #3 的第⼀个字节。
指向 #4 的第⼀个字节是个相对指针，它需要 RCV.NXT 指针加上 RCV.WND ⼤⼩的偏移ᰁ，就可以指向 #4 的
第⼀个字节了。

流量控制

发送⽅不能⽆脑的发数据给接收⽅，要考虑接收⽅处理能⼒。
如果⼀直⽆脑的发数据给对⽅，但对⽅处理不过来，那么就会导致触发重传机制，从⽽导致⽹络流重的⽆端的浪费。

为了解决这种现象发⽣，TCP 提供⼀种机制可以让「发送⽅」根据「接收⽅」的实际接收能⼒控制发送的数据量，
这就是所谓的流量控制。

1、假如发送方报文丢失，那么接收方回传的ack会一直不包含丢失字段，则发送方会在重传等待时间结束后对丢失报文段进行重传。接收方利用接受窗口大小这个参考，控制发送方的发送速率。

2、假如接收方有了新的可缓存空间，并将消息发送给发送方的途中，报文丢失，那么发送方一直以为接收方没有空间接收，而接收方也并不知道自己的报文丢失。这样就陷入死锁状态。为了打破死锁，发送方每发送一次报文都会启动一个持续计时器，当持续计时器超时的时候，发送零窗口探测报文。询问是否依旧是没有缓存空间。零窗口探测报文对于接收方没有空间要求，且也有超时重传机制。

拥塞控制

前⾯的流量控制是避免「发送⽅」的数据填满「接收⽅」的缓存，但是并不知道⽹络的中发⽣了什么。

而拥塞控制是当⽹络发送拥塞时，TCP 会⾃我牺牲，降低
发送的数据量。控制的⽬的就是避免「发送⽅」的数据填满整个⽹络。

拥塞控制主要是4个算法：

• 慢开始：从1开始倍数增长。

• 拥塞避免：如果当拥塞窗⼝ cwnd 「超过」慢启动⻔限 ssthresh就进入拥塞避免算法。一般ssthresh的大小是65535。进入拥塞避免算法后，每次线性增加1。如果网络发送拥塞，有丢包现象发生，就会触发重传机制，将ssthresh 设为 cwnd/2，cwnd窗口值设置为1，并执行慢开始算法。
  

• 快重传：发送方一旦收到3个连续的重复确认，立即重传相应报文段。TCP认为在还能收到3个连续重复确认的情况下，说明大部分没丢，只是丢了一小部分。于是将cwnd拥塞窗口设置为原来的一半，将ssthresh设置为cwnd，然后进入快速恢复算法。

• 快恢复：拥塞窗口 cwnd = ssthresh + 3（3的意思是确认有3个数据包收到了），重传丢失的数据包，如果再收到重复的ACK，那么cwnd增加1.

UDP协议

应用层

HTTP

HTTP 是⼀个在计算机世界⾥专⻔在「两点」之间「传输」⽂字、图⽚、⾳频、视频等「超⽂本」数据的「约定和
规范」

HTTP状态码

1xx 类状态码属于提示信息，是协议处理中的⼀种中间状态，实际⽤到的⽐较少

2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态

• 「200 OK」是最常⻅的成功状态码，表示⼀切正常。如果是⾮ HEAD 请求，服务器返回的响应头都会有 body数据
• 「204 No Content」也是常⻅的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。
• 「206 Partial Content」是应⽤于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，⽽是其中的⼀部分，也是服务器处理成功的状态

3xx 类状态码表示客户端请求的资源发送了变动，需要客户端⽤新的 URL新发送请求获取资源，也就是重定向。

• 「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改⽤新的 URL 再次访问。
• 「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要⽤另⼀个 URL 来访问。
• 301 和 302 都会在响应头⾥使⽤字段 Location ，指明后续要跳转的 URL，浏览器会⾃动重定向新的 URL。
• 「304 Not Modified」不具有跳转的含义，表示资源未修改，᯿定向已存在的缓冲⽂件，也称缓存重定向，⽤于缓存控制

4xx 类状态码表示客户端发送的报⽂有误，服务器⽆法处理，也就是错误码的含义。

• 「400 Bad Request」表示客户端请求的报⽂有错误，但只是个笼统的错误。
• 「403 Forbidden」表示服务器禁⽌访问资源，并不是客户端的请求出错。
• 「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以⽆法提供给客户端。

5xx 类状态码表示客户端请求报⽂正确，但是服务器处理时内部发⽣了错误，属于服务器端的错误码。

• 「500 Internal Server Error」与 400 类型，是个笼统通⽤的错误码，服务器发⽣了什么错误，我们并不知道。
• 「501 Not Implemented」表示客户端请求的功能还不⽀持，类似“即将开业，敬请期待”的意思。
• 「502 Bad Gateway」通常是服务器作为⽹关或代理时返回的错误码，表示服务器⾃身⼯作正常，访问后端服务器发⽣了错误。
• 「503 Service Unavailable」表示服务器当前很忙，暂时⽆法响应服务器，类似“⽹络服务正忙，请稍后重试”的意思。

GET和POST的区别？

Get （获取）⽅法的含义是请求从服务器获取资源，这个资源可以是静态的⽂本、⻚⾯、图⽚视频等。

POST（投递） ⽅法则是相反操作，它向 URI 指定的资源提交数据，数据就放在报⽂的 body ⾥。

HTTP和HTTPS的区别？

1. HTTP是超文本传输协议，信息是明文传输，存在安全风险问题，HTTPS则解决了HTTP不安全的缺陷，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，使得报文能够加密传输。
2. HTTP连接建立简单，TCP三次握手之后便可以进行HTTP的报文传输，而HTTPS在TCP三次握手之后，还需要进行SSL/TSL握手，才可以进入加密报文传输。
3. HTTP的端口号是80，HTTPS的端口号是443
4. HTTPS协议需要向CA(证书权威机构)申请数字证书，来保证服务器身份是可信的。

HTTPS解决了HTTP哪些问题，是怎么解决的？

HTTP由于是明文传输，安全上存在窃听、篡改和冒充的风险。
HTTPS在HTTP与TCP层之间加入了SSL/TSL协议，通过对信息的混合加密，防止窃听；采用校验机制，使用摘要算法，为数据生成独一无二的指纹，用于校验数据的完整性，防止数据篡改；将服务器公钥放入到数字证书中，解决身份冒充的风险。

SLL/TLS协议基本流程

• 客户端向服务器索要并验证服务器的公钥
• 双方协商生成会话秘钥
• 双方采用会话秘钥进行加密通信

前两步也就是SSL/TSL的建立过程，也就是握手阶段。

HTTP/1.1、HTTP/2、HTTP/3演变

域名解析协议（DNS，Domain Name System）

1. 客户端⾸先会发出⼀个 DNS 请求，问 www.server.com 的 IP 是啥，并发给本地 DNS 服务器（也就是客户端
   的 TCP/IP 设置中填写的 DNS 服务器地址）。
2. 本地域名服务器收到客户端的请求后，如果缓存⾥的表格能找到 www.server.com，则它直接返回 IP 地址。如
   果没有，本地 DNS 会去问它的根域名服务器：“⽼⼤， 能告诉我 www.server.com 的 IP 地址吗？” 根域名服
   务器是最⾼层次的，它不直接⽤于域名解析，但能指明⼀条道路。
3. 根 DNS 收到来⾃本地 DNS 的请求后，发现后置是 .com，说：“www.server.com 这个域名归 .com 区域管
   理”，我给你 .com 顶级域名服务器地址给你，你去问问它吧。”
4. 本地 DNS 收到顶级域名服务器的地址后，发起请求问“⽼⼆， 你能告诉我 www.server.com 的 IP 地址吗？”
5. 顶级域名服务器说：“我给你负责 www.server.com 区域的权威 DNS 服务器的地址，你去问它应该能问到”。
6. 本地 DNS 于是转向问权威 DNS 服务器：“⽼三，www.server.com对应的IP是啥呀？” server.com 的权威 DNS
   服务器，它是域名解析结果的原出处。为啥叫权威呢？就是我的域名我做主。
7. 权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。
8. 本地 DNS 再将 IP 地址返回客户端，客户端和⽬标建⽴连接。

为什么域名解析用UDP协议？

因为UDP快啊！UDP的DNS协议只要一个请求、一个应答就好了。
而使用基于TCP的DNS协议要三次握手、发送数据以及应答、四次挥手，但是UDP协议传输内容不能超过512字节。
不过客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。

动态主机配置协议（DHCP，Dynamic Host Configuration Protocol）

Linux网络编程

TCP的socket编程

1. 服务端和客户端初始化 socket ，得到⽂件描述符；
2. 服务端调⽤ bind ，将绑定在 IP 地址和端⼝;
3. 服务端调⽤ listen ，进⾏监听；
4. 服务端调⽤ accept ，等待客户端连接；
5. 客户端调⽤ connect ，向服务器端的地址和端⼝发起连接请求；
6. 服务端 accept 返回⽤于传输的 socket 的⽂件描述符；
7. 客户端调⽤ write 写⼊数据；服务端调⽤ read 读取数据；
8. 客户端断开连接时，会调⽤ close ，那么服务端 read 读取数据的时候，就会读取到了 EOF ，待处理完数据后，服务端调⽤ close ，表示连接关闭。

需要注意的是：监听的 socket 和真正⽤来传送数据的 socket，是「两个」 socket，⼀个叫作监听 socket，⼀个叫作已完 成连接 socket。

成功连接建⽴之后，双⽅开始通过 read 和 write 函数来读写数据，就像往⼀个⽂件流⾥⾯写东⻄⼀样。

Linux内核中会维护两个队列：

• 半连接队列（SYN 队列）：接收到⼀个 SYN 建⽴连接请求，处于 SYN_RCVD 状态；
• 全连接队列（Accpet 队列）：已完成 TCP 三次握⼿过程，处于 ESTABLISHED 状态；