Linux网络——传输层

目次
1. 再谈端标语
2. UDP
① UDP 协议的报文
② UDP 协议报头的本质 
3. TCP
① TCP 缓冲区的明白
② TCP 协议的报文
1. 16位源端标语 && 16位目标端标语 && 4位首部长度
2. 16位窗口巨细
3. 32位序号 && 32位确认序号
4. 六个标记位
③ TCP 的面向毗连特性
④ TCP 的可靠传输特性
1. TCP 确认应答机制
2. TCP 超时重传机制
3. TCP 流量控制
4. TCP 滑动窗口
5. TCP 耽误应答
6. TCP 捎带应答
7. TCP 拥塞控制
⑤ TCP 可靠与服从小结
⑥ TCP 的面向字节省特性
粘包题目 
⑦ TCP 的非常情况
4. 文件与 socket 的关系

---

我们之前已经谈到过传输层负责的是包管数据可以或许完备的从发送端发送到吸收端
1. 再谈端标语

我们将 源IP、源端标语、目标IP、目标端标语、协议号 五元组标识为一个通讯。我们来看看端标语的分别
   0~1023：着名端标语，包罗 HTTP、FTP、SSH 等广为人知的协议
  1024~65535：OS 动态分配的端标语
  我们来看看一些常见的着名端标语
   SSH -> 22
  FTP -> 21
  telnet -> 23
  HTTP -> 80
  HTTPS -> 443
  我们在利用端标语时，应该只管制止利用这些较为着名的端标语，别的我们之条件到过，一个进程可以绑定多个端标语，但是一个端标语是不能被多个进程绑定的！ 
我们可以利用 netstat 来检察通讯情况，如图

2. UDP

之前我们曾说过，在学习一个新层级时必要学习下面几个东西
   1. 报头与有效载荷怎样分离
  2. 有效载荷应该交付给上层的哪个协议
  3. 熟悉报头
  4. 学习该协议的干系题目
  ① UDP 协议的报文

UDP 协议的报文如图所示

源端标语与目标端标语不必多说，我们将 UDP 长度减去一个8，就能得到正文长度，稍微盘算一下正文的最大长度
   2 ^ 16 Byte = 64 KB
  那假如必要传输的数据巨细高出了64KB，我们还能利用 UDP 来传输吗？——可以！不外我们要将自己的报文拆解成 64KB 然后再发送； 而我们用 UDP 查验和来查验整个报文是否完全送达，假如发现数据堕落，就会将当前报文直接抛弃。
可以看到，整个 UDP 运作的模式根本上有三个特点，即
   无毗连
  不可靠
  面向数据报
  注：面向数据报意为：应用层交给了 UDP 多长报文，UDP 照原样发送，既不拆分也不归并。举个例子，发送端调用一次 sendto 函数发送100字节的数据，吸收端也只能一样操纵，不能循环调用10次 recvfrom 函数，每次吸收10字节。也是因此缘故起因，我们可以说 UDP 没有真正意义上的发送缓冲区，如图

固然 UDP 也是全双工的工作模式，但是假如有一方的缓冲区满了之后，再吸收到 UDP 报文就会将其直接舍弃。
② UDP 协议报头的本质 

我们必要知道，Linux 体系自己是利用 C 语言写的，也就是说整个报头在现实上是如下这种情势

1. // 报头
2. struct udp_header
3. {
4.     // 使用位段来划分各个部分
5.     uint32_t src_port:16;   // 源端口号
6.     uint32_t dst_port:16;   // 目的端口号
7.     uint32_t length:16;     // UDP 长度
8.     uint32_t check_code:16; // UDP 检验和
9. }

复制代码

而 OS 会为其提供一个缓冲区，也就是说现实利用如图所示

如许就通过先形貌后构造完成了 UDP 的利用。
我们末了再先容一些基于 UDP 协议的应用层协议
   NFS: 网络文件体系协议，实现跨网络访问文件。
  TFTP: 简单文件传输协议，用于装备固件升级。
  DHCP: 动态主机设置协议，主动分配网络设置。
  BOOTP: 引导步调协议，用于主动网络设置。
  DNS: 域名体系，将域名分析为IP地点。
  3. TCP

① TCP 缓冲区的明白

TCP 的全名为 Transmission Control Protocol，即传输控制协议，如图

传输控制协议在整个过程中决定命据在什么时间发送，发送多少，发送堕落了怎么办？也就是说，这些题目全部由 TCP 协议自主决定！而上层在调用诸如 write, read, send, recv 等函数时，其本质并不是将数据发送到网络中，而是将数据拷贝到 Linux 内核中，由 TCP 决定命据何时发送等。而发送缓冲区自己也存在于 Linux 中，也就是由多个 4KB 的struct_page 构成的。以是，我们在学习网络时，将网卡更换为磁盘，团体与文件管理相似。
② TCP 协议的报文

TCP 协议的报文如图所示

接下来我们来看看各个字段的意义
1. 16位源端标语 && 16位目标端标语 && 4位首部长度

之前我们说过，要想学习一个协议，起首必要相识怎样将有效载荷与报头分离？分离出来后怎样将有效载荷交付给上层？
交付给上层很简单，我们在学习 UDP 协议的时间已经学过，只要有源端标语与目标端标语就可以有效交付。
接下来就是有效载荷怎样与报头分离的题目，我们可以除有效载荷外，我们利用的是固定长度报头 + 自界说形貌，而报头长度为20位，而选项长度为40位
   4位首部长度就可以很好地办理这个题目，4个数位可以表现 [0, 15] 范围的数字，我们在盘算的时间，会以4字节为单位，也就是说4个数位可以表现 [0, 60] 字节的范围
  举几个例子
   假如首部长度的数字为 0101 -> 5 -> 5*4字节 -> 20，意思是这个报文不带选项；
  假如首部长度的数字为 1101 -> 13 -> 13*4字节 -> 52，意思是这个报文带32字节的选项。
  而将整个报文减去这个长度就能得到有效载荷！ 
2. 16位窗口巨细

传输过程如图所示

整个通讯过程是基于 TCP 协议的，也就是说，互发消息时，任何一方发送的都是一个完备的 TCP 报文，即肯定携带完备的 TCP 报头。那我们为什么说相对于 UDP 来说，TCP 是可靠的呢？
   TCP 为了包管可靠性，最根本的一个特点就是确认应答机制！具体一点来说，就是不管是客户端还是服务端，在发送了任何消息后，都必要收到回应，如图所示
   

回到这个16位窗口巨细，我们必要先相识一下游量控制机制
   流量控制：吸收方的吸收缓冲区快满或已满时，会让发送方减缓发送频率大概不发，从而镌汰丢包率
  那我们要让发送方发慢一点，依据是什么呢？——16位窗口巨细中填写的是 自己的吸收缓冲区 中 剩余的空间巨细，我们先条件到过每次发送信息与确认应答都带有一个完备的 TCP 报文，而当发送方收到相应后，会根据吸收方的吸收缓冲区剩余空间巨细来控制发送速率！以是，16位窗口巨细填写的是吸收方的吸收缓冲区的剩余巨细。
3. 32位序号 && 32位确认序号

我们来想想，天下上存在完全可靠的网络协议吗？肯定不是，那么我们可以退而求其次，即包管局部上的可靠即可，举个例子
   在操场的百米跑道上站着两个人(A 与 B)，A 向 B 扣问“你吃了吗？”，B 向 A 答复“收到！”，B 向 A 再答复“吃了！”，A 向 B 答复“收到！”
  在这个例子中
   1. 只要收到了应答，就能确认自己迩来发送的消息被对方收到了
  2. 我们也能发现，假如没有应答的数据，我们就无法包管可靠性，因此最新的一条消息是没有应答的，以是无法包管发送出去的消息是 100% 可靠的
  那为了包管可靠性，假如在一段时间内没有收到应答的话，发送方就会以为数据丢失，然后举行重传。而在操场传话的例子中，答复收到后再答复吃了这一活动服从有点低，因此我们可以将他们合在一起，也就是 捎带应答。在现实的 TCP 运行中，发起哀求操纵一样平常来说都是并行的，如图

而由于我们一次性发了很多个报文，经转多个装备，终极吸收方吸收到的序次大概会差异（如4132），也就是说出现了乱序题目，这会导致 TCP 变得不可靠，因此我们必要利用32位序号来包管数据的按序到达（如1234等序号）！
那么32位序号是什么呢？如图所示

发送的数据块的末了一个字符的下标就是32位序号中要填入的内容！那32位确认序号又是什么？——添补的是序号报文的+1数字，为什么呢？
   确认序号的意义是确认之前的数据，我如今已经收到了，下一次发送数据请从确认序号处开始发送
  举个例子

假如在收到确认应答时，收到了3001与4001而没有收到1001与2001，我们以为前3000个数据都收到了，也就是说 TCP 答应应答有少量的缺失。这里另有一个疑问，我们只必要将序号+1填回序号中返回即可，那为什么还要有确认序号呢？——由于捎带应答的存在，大概吸收方也有自己要发送的数据，以是必要利用序号来发送数据！
4. 六个标记位

TCP 在举行通讯时，会有很多活动，好比：创建毗连，举行通讯，断开毗连等，也就是说 TCP 收到的报文自己是有各种范例的。而差异的范例决定了吸收方要做差异的动作！那吸收方怎样得知报文的范例呢？——检察六个标记位，也就是说六个标记位的存在意义就是区分 TCP 的报文范例。
六个标记位分别是：URG(Urgent Pointer), ACK(Acknowledgment), PSH(Push Function), RST(Reset), SYN(Synchronize), FIN(Finish)
具体来说
   ACK：确认，表现确认序号字段是有效的，用于确认已乐成吸收的数据，即表现这是一个确认应答报文。
  SYN：同步，表现哀求创建毗连，即表现这是一个同步报文。
  FIN：竣事，表现发送方已经发送完毕，哀求关闭毗连。
  我们怎样明白“毗连”这一活动呢？——服务器对客户端举行先形貌后构造！
   PSH：推送，提示吸收方立刻从 TCP 缓冲区中将数据读走
  假如上层(如 CP 模子)不绝不取数据的话，就会导致吸收缓冲区变满，如许就会让发送端发送不了数据(在 OS 体系层面的表现是同步与互斥，OS 网络层面的表现则是流量控制)，也就是说吸收缓冲区越大，另一端发送的速率就越快。
   RST：重置，表现要求重新创建毗连，即表现这是一个复位报文。
  三次握手如图所示

什么时间 C 与 S 以为自己已经完成毗连了呢？——只要以为自己发出去了 ACK 就以为乐成！TCP 固然包管可靠性，但是 TCP 是答应创建毗连失败的，也就是说 TCP 在举行三次握手时大概会出现题目，那就是万一发出去的 ACK 丢失，CS 对于创建毗连的认知就会产生差异等(C 以为创建毗连乐成，S 以为没有创建毗连)！
为了办理这个题目，假云云时 C 向 S 发送数据，S 给 C 的应答报文中带上 RST，C 就会心识到创建未乐成，然后重新发送毗连哀求。 
   URG：告急指针，表现16位告急指针有效，即数据包中有告急数据，必要优先处置处罚
  举个例子
   假设如今有一个 TCP 数据段，序列号是 1000，而且该段的 URG 标记被设置为 1，告急指针为 50。序列号 1000 表现这个数据段的起始位置。告急指针 50 表现从序列号 1000 开始，告急数据竣事于序列号 1050。由于 URG 标记被设置为 1，吸收方就知道数据段中的序列号范围 [1000, 1050) 这部分数据是告急数据，应该优先处置处罚。
  我们再举一个现实中的例子，假如如今有一个服务器，当客户端多次向服务器发起哀求后，服务器没有任何反应，此时就必要以告急指针的方式扣问服务器的状态！ 
③ TCP 的面向毗连特性

如图，TCP 是一个基于毗连的协议，整个通讯的创建和断开又叫做 三次握手 和 四次挥手！
那么为什么必要三次握手呢？
   1. 可靠地验证全双工工作模式
  2. 只要是奇数次的握手都可以创建毗连！
  那我们为什么要接纳三次握手呢？假如是一次握手的话，很轻易将服务器的毗连队列占满，也就是会导致 SYN 洪流；假如是两次握手也会导致 SYN 洪流的情况。这两种方式都优先让 Server 端做出创建毗连的动作，而利用三次握手可以将这个动作嫁接到 Client 端，即三次握手能确保在一样平常情况下，握手失败后的毗连本钱是嫁接在 Client 端的，同时在这个握手过程中 C 与 S 都能可靠地包管一次报文的收与发，这也能验证全双工通路是否通畅！
那为什么要举行四次挥手呢？
   假如想断开毗连，意思就是没有数据给对方发送了，但是发送数据这个活动是两边都有大概会做的，因此必要断开两次！也就是所谓的四次挥手。
  接下来让我们看看整个毗连过程中的细节
   1. 毗连的创建与 accept 函数无关，也就是说三次握手是两边的 OS 主动完成的
  2. listen(listenfd, backlog) 函数中，第二个参数是什么？
  如图

backlog 表现这个全毗连队列的最大长度，accept 函数现实就是向这个队列中添加一个新元素，这个参数为什么不能太长呢？
   假如上层不绝不取走，而下层却不绝添加，就会导致资源被占据而没有创造代价，因此这个长度一样平常来说是视情况而定的！
  那可不可以没有这个参数呢？——不可！
   举个简单的例子，一样平常海底捞的店门口都会放上一些椅子，当店内没有满载时就可以直接进入，如许的计划可以让服务器充实利用资源。 
  而除了全毗连队列以外，还存在一个队列
   在服务端第一次吸收到毗连哀求后会进入 SYN_RCVD 状态，也就是说被毗连的一方处于 SYN_RCVD 状态，也称为半毗连，而对于半毗连队列来说，半毗连节点并不会长时间举行维护。 
    3. 在四次挥手中，主动断开毗连的一方，在四次挥手完成后，要进入 TIME_WAIT 状态，然后等候多少时间后，主动开释 
  也就是说，假如是服务器发起的断开毗连，在一段时间内是无法利用同一端标语重启的！我们可以利用 setsockopt 来关闭这一活动。
那为什么要进入 TIME_WAIT 状态呢？它会一连多长时间呢？
   TIME_WAIT 状态可以让两边的汗青数据得以消散。从而防止对后续的通讯造成伤害；还可以让我们断开毗连(四次挥手)具有较好的容错性。举个例子
    在 TCP 的四次挥手关闭过程中，假如客户端发送的末了一个ACK在网络中丢失，那么服务器端会由于超时未收到确认而重传FIN包。假如客户端不进入TIME_WAIT状态，而是直接关闭毗连，那么当服务器端重传FIN包时，客户端将无法辨认并相应这个FIN包，导致服务器端无法正常关闭毗连。TIME_WAIT状态确保了客户端在富足长的时间内可以或许吸收到服务器端大概重传的FIN包，并发送相应的ACK确认，从而包管毗连可以或许可靠地关闭 
    TIME_WAIT 的一连时间一样平常是 2个MSL(一个报文在网络中存在的最长时间)，而一个  MSL 在 RFC1122 定制的标准中规定为 2 分钟，也就是说 TIME_WAIT 现实的一连时间大概在 60s ~ 120s 左右。
  ④ TCP 的可靠传输特性

1. TCP 确认应答机制

如图所示

确认应答机制就是在每次收到报文后，都会向发送方回应一个应答报文。
2. TCP 超时重传机制

如图所示

对于这个特定时间隔断来说
   最理想的情况下，我们应该找到一个最小的时间，以包管"确认应答肯定能在这个时间内返回"。但是这个时间的是非，随着网络情况的差异，会产生差异，也就是说：假如我们设置的超时时间太长，会影响团体的重传服从；但是假如设置的超时时间太短，有大概会频仍发送重复的包！
  那我们怎样办理这个题目呢？
   TCP 为了包管无论在任何情况下都能比力高性能的通讯，会动态盘算这个最大超时时间。
  
  在 Linux 中(BSD Unix 和 Windows 也是云云)，超时以 500ms 为一个单位举行控制，每次判断超时重发的超时时间都是500ms的整数倍。假如重发一次之后，仍旧得不到应答，等候 2*500ms 后再举行重传；假如仍旧得不到应答，等候 4*500ms 举行重传。以此类推，超时时间以指数情势递增。累计到肯定的重传次数，TCP 会以为网络大概对端主机出现非常，从而逼迫关闭毗连。
  如今让我们想想另一个题目：对于 S 端来说，若其被 C 端举行超时重传发送了重复报文怎么办？
   报文是有序号的！S 端可以根据序号来对报文举行去重。 
  3. TCP 流量控制

我们在前面先容 16位窗口巨细时已经提到了流量控制，接下来我们更加深入的相识一下
流量控制如图所示

对吸收端来说，一旦窗口更新关照在传送途中丢失，会导致两边无法继续通讯，因此发送端主机时不时就会发送窗口探测包。接下来我们另有几个题目 
   1. 我们在第一次发送数据的时间，怎么包管发送的数据量是公道的呢？
  三次握手做到的事不但仅是握手，在握手这个过程中 CS 两边已经互换了报文，也就是已经协商好了两边的吸收本事！
   2. 由于已经协商好了吸收本事，以是第三次握手的时间可以携带一部分数据！也就是我们所说的捎带应答
  TCP 窗口巨细最大为 65535字节吗？——并不是，TCP 选项中有一个 M 选项(窗口扩大因子)，TCP 窗口的现实巨细为 窗口巨细左移 M 位。
   3. 流量控制是属于 TCP 的可靠特性，还是属于服从特性呢？——可靠为主，服从为辅！
  4. TCP 滑动窗口

现实的交换过程图如下

在这个数据传输过程中，已经发送出去的，但是暂时没有收到应答的报文，会被 TCP 暂时生存起来，如许的报文发送方大概会存在很多个，那这些报文会被生存到那里呢？发送缓冲区如图所示

此中，对于已发送已确认的地域，我们会将其设置为可被覆盖的状态，如许就叫做从 TCP 发送缓冲区中移除它了！而我们将已经发/可以发送数据但是尚未收到应答的地域称为 滑动窗口！正是由于有滑动窗口地域，才气一次向对方发送最大的 TCP 报文。
它是否与我们学过的算法中的滑动窗口(算法——滑动窗口)有关系呢？——有的，窗口滑动本质上指的就是指针右移！那么我们另有几个疑问
   1. 滑动窗口在那里？——发送缓冲区的一部分
  2. 滑动窗口的范围巨细是多少？——如今我们以为是对方的吸收窗口的巨细
  3. 怎样明白发送缓冲区的地域分别？——通过指针/下标区分即可
  滑动窗口如图所示

我们对于确认序号的界说如下
   假如确认序号是 X，则 X 之前的报文我们都收到了，这个过程答应少量的 ACK 丢失 
  确认序号包管了滑动窗口线性地向后更新，不会出现跳跃的情况。 接下来我们加深一下对滑动窗口的明白
   1. 假如在传输过程中出现了丢包题目，我们怎样明白滑动窗口？ 
  假如 1~1001, ... , 4001~5000 的 ACK 丢失了，但是 5001~6000 的 ACK 没丢失怎么办？——不怕有什么影响，只要收到了 5001~6000 的应答报文，就直接将滑动窗口的左端指针移动到 6001即可。
那假如 1~1001, ... , 4001~5000 的 ACK 没丢失，但是 5001~6000 的 ACK 丢失了怎么办？——将滑动窗口的左端指针移动到 4001，然后对 4001 厥后的数据举行补发即可。
那假如在数据的传输过程中，吸收方没有收到 1001~2000 的数据，而收到了1~1000 与 2001~6000 的数据怎么办？——如图所示

我们将一连收到3个同样的 ACK 后举行补发这一活动，称为快重传。那已经有了快重传这一机制，为什么我们还要有超时重传呢？——快重传是有条件的，它是为了进步服从而存在的，而超时重传是兜底的。
   2. 怎样明白滑动窗口中的指针向右移动？移动的时间，巨细会厘革吗？怎么厘革？会变为0吗？
  我们先答复反面的题目，巨细是会厘革的，一样平常来说巨细是动态厘革的，也大概会酿成0。指针在右移的时间，一样平常有3种情况
   1. 右指针不动，左指针移动 -> 范围缩小
  2. 左右指针都移动 -> 范围扩大
  3. 左右指针都移动 -> 范围缩小
  左指针 = 收到简直认序号，右指针 = 确认序号 + min(窗口巨细，有效数据)，我们之前讲的流量控制就是通过滑动窗口来举行控制的，它不但能将传输速率往小了控制，也能往大了控制。
   3. 滑动窗口在发送缓冲区中移动指针会发生越界的情况吗？
  不会的，TCP 的滑动窗口机制是基于一种“环形缓冲区”的头脑计划的。通过这个机制，发送方和吸收方在创建毗连时会协商一个初始序号（比方 1234）。从这个初始序号开始，数据会被分配到序号加上数组下标的相应位置。由于滑动窗口利用环形缓冲区的方式，发送方的“发送指针”会随着数据的发送和确认徐徐进步。假如发送窗口到达发送缓冲区的末端，它会“回绕”到缓冲区的起始位置，继续发送未发送的数据。因此，滑动窗口的指针不会越界，它始终会保持在有效的缓冲区范围内。
5. TCP 耽误应答

在 CS 端相互发送数据的时间，我们已经知道，发送方一次发送更多的数据，发送的服从就会更高，也就是说发送方以为吸收方可以或许继承更多的数据，如许的服从就会变高，意味着吸收方应该只管给发送方转达一个更大的窗口！
那我们怎样让吸收方给对方告示一个更大的窗口呢？——收到报文不发急应答，也就是耽误应答，这从根本上来说是一个赌概率的时机，赌上层可否尽快地取走数据，从而耽误应答时能回应一个更大的窗口。也是因此，假如我们要计划一个服务器，我们比力保举的做法就是每次都尽快地通过read, recv 等函数将数据全部从 TCP 中拿上来！
那么全部的包都可以耽误应答么？固然不是，耽误应答有数量限定与时间限定，即
   数量限定：每隔N个包就应答一次
时间限定：高出最大耽误时间就应答一次
  具体的数量和超时时间，差异的操纵体系有差异。一样平常来说 N 取 2，超时时间取 200ms。
6. TCP 捎带应答

捎带应答（piggybacking）是 TCP 协议中一个常见的机制，尤其是在数据传输阶段。这个机制具体来说是指在某个数据包的应答（ACK）中“捎带”回传数据，制止单独发送确认包，从而进步服从，镌汰网络负担。
7. TCP 拥塞控制

如今我们学习到的险些全部战略，都是在两头的呆板上起作用的。而 TCP 还为我们思量了网络的题目——也就是拥塞控制！
假如恣意主机在发送数据的时间出现了题目，这个题目大概不但仅是对方主机出现了题目，也有大概是网络出现了题目。举个例子
   

• 假如通讯的时间，出现了少量的丢包 -> 正常情况
  
• 假如通讯的时间，出现了大量的丢包 -> 网络出现了题目
  

 这个网络出现了题目只是一个笼统的概述，具体题目大概是硬件出现了题目，也有大概是数据量太大，引起了壅闭。
假如通讯两边都出现了大量的数据丢包(大量数据超时)题目，那么 TCP 就会判断网络出题目了(网络拥塞了)。那我们作为发送方，应该怎么办呢？——暂缓一下，间歇性的发送少量数据，绝对不能立刻对报文举行超时重发！如许做只会加重网络的拥塞情况。
由于各台主机均利用 TCP/IP 协议，以是网络出现了拥塞对多台主机来说是“共识”，因此拥塞控制的战略是每台辨认到当前网络已经拥塞的主机都要做的事。现实上，滑动窗口的巨细着实也与拥塞窗口干系，即
   滑动窗口巨细 = min(吸收窗口巨细，拥塞窗口巨细)
  吸收窗口巨细思量的是对方主机的吸收本事，而拥塞窗口巨细则思量的是动态的网络的吸收本事。以是我们如今可以重新界说一下滑动窗口的右指针了，即
   右指针 = min(吸收窗口，有效数据，拥塞窗口) 
  拥塞窗口是主机判断网络康健程度的指标，假如高出了拥塞窗口，会引发网络拥塞，反之则不会。假如网络出现了拥塞，当两边发送少量报文都表现可行的时间，网络应该趋于康健了，此时应当尽快规复正常通讯了！但是网络是动态的，以是拥塞窗口肯定不是静态的，如图所示

⑤ TCP 可靠与服从小结

如今我们可以看到 TCP 为了数据传输的可靠性，接纳了如下方案
   

• 校验和
  
• 序列号(按序到达) -> 去重工作
  
• 确认应答 -> 包管可靠性的核心战略
  
• 超时重发
  
• 毗连管理
  
• 流量控制
  
• 拥塞控制
  

而为了提供数据传输的服从，接纳了如下方案 
   

• 滑动窗口
  
• 快速重传
  
• 耽误应答
  
• 捎带应答
  

⑥ TCP 的面向字节省特性

面向字节省的意思是读写不必要逐一匹配，对用户层来说，用户只关心应用层的协议；对于传输层来说，OS 负责具体的网络通讯细节。由于缓冲区的存在，TCP 步调的读和写不必要逐一匹配，举个例子
   

• 写 100 个字节数据时，可以调用一次 write 写 100 个字节，也可以调用 100 次 write ，每次写一个字节。
  
• 读 100 个字节数据时，也完全不必要思量写的时间是怎么写的，既可以一次 read 100 个字节，也可以一次 read 一个字节，重复 100 次。
  

在 TCP 这一层，它并不关心上层协议，也不关心上层的报文格式，只有字节的概念！
在应用层这一层，用户对报文举行处置处罚必须一个一个举行处置处罚！将提取上来的字节省转换成一个一个完备的哀求，这之后举行反序列化。
粘包题目 

假如用户在提取字节省后没有将其处置处罚成一个个哀求大概少处置处罚了几个哀求，对于应用层来说就会产生粘包题目，而我们办理粘包题目最简单的做法就是定制协议！这也是我们在做网络版盘算器时封装了 Encode 与 Decode 函数的缘故起因(详见Linux网络——应用层中的网络盘算器)。
以是，怎样办理用户层粘包题目呢？——在应用层通过协议，明确报文与报文之间的边界。举几个例子
   1. 利用定长报文
  2. 利用特别字符
  3. 利用自形貌字段 + 定长报头
  4. 利用自形貌字段 + 特别字符(如 HTTP)
  ⑦ TCP 的非常情况

TCP 协议自己是基于毗连的，而毗连自己是和文件直接干系的！文件的生命周期是跟随进程的。假如在 CS 两边进程通讯时，假如 C 端由于一些缘故起因导致进程克制，那么毗连就会正常克制。那要是 C 端直接断电/网线断开，那 S 端会不绝维持住 TCP 吗？——TCP 有保活机制，即 S 端在一段时间内不会断开，而高出了肯定时间会主动断开。
4. 文件与 socket 的关系

如图所示

对于我们如今学习的协议栈来说，OS 负责的是传输层与网络层，OS 在每一层中必要做的只有两件事
   1. 利用特定的数据布局表述协议
  2. 天生与特定协议相匹配的方法集
  而对于每一层来说，均会收到多个报文，服务器必要对他们举行先形貌后构造，我们检察 Linux 内核可以看到

毕竟上，我们在协议栈中向上向下交付，本质上就是在向头空间/尾空间添加报头，也就是说我们必要举行的封包与解包操纵本质就是在移动指针！而我们在差异层间移动时，并不必要举行频仍的拷贝，只必要移动指针即可！