伪文件是什么？#

• 伪文件（pseudo file）是一种特殊的文件，它不对应于实际的物理存储，所以有时也被称为虚拟文件（virtual file），因为它们并不实际存在于磁盘上，而是通过内核提供的接口动态生成的
• 在 Linux 系统中，伪文件常用于与系统内核进行交互，获取系统信息或调整系统参数

读取伪文件会返回0吗？#

• 取决于文件的内容和读取的方式

• 一般来说，读取伪文件时不会返回0。读取伪文件时返回的非零值，表示已读取的字节数，因为伪文件是在内存中动态生成的，并没有一个确定的文件大小。因此，如果读取伪文件时返回0，则通常表示读取失败或到达了文件末尾，而不是表示文件实际大小为0

• 但是，有些伪文件可能会返回0，这取决于具体的实现方式和应用场景

• 例如，在某些系统中，/proc/stat 文件的第一行可能会返回0，表示系统启动以来的CPU利用率。这是因为第一行的数据是累加值，而不是实时值，所以在系统启动后第一次读取该文件时会返回0

白哥讲的？？？#

• 读取时会不会返回0？？？
  • 读取普通文件时会遇到
    • 读到末尾，返回0，文件结尾标志EOF
      • 协议栈干的，收到fin后，会在socket的末尾放一个EOF
    • 读普通文件read不会阻塞，普通文件没阻塞这个属性
  • 读设备或者管道套接字，一般不会
• 管道有没有写端？？？
  • 就是有没有管道的文件描述符？没有的话会被系统自动释放掉
    • 管道是内核空间的内存，不会轻易泄漏
• 管道有没有数据？？？
  • 以后有没有可能有数据？
    • 没有数据，写端也没有，未来肯定没有数据，会直接返回
    • 没有数据，有写端，未来可能有数据，等待

listen详细介绍参考文章#

文章链接

listen的定义#

• 在Linux下listen()的定义是这样的

1
#include <sys/type.h>
2
#include <sys/socket.h>
3
int listen(int fd , int backlog)

• listen()一般用在bind()之后accept()之前，其中第一个参数是通过scoket()函数获得的套接字编号，第二个参数backlog是他所能监听的最大套接字数量

listen的第二个参数#

• listen的第二个参数backlog，backlog的含义众说纷纭，其中有以下说法：

  • １．SYN队列的大小
  • ２．ACCEPT队列的大小
  • ３．是SYN+ACCEPT的大小

• 下面是实践验证：

• 要验证的点有两个：

  • 1.connect在三次握手后就会返回
  • 2.backlog的具体含义

1
// 服务器代码
2
#include <stdlib.h>
3
#include <stdio.h>
4
#include <string.h>
5
#include <sys/types.h>
6
#include <errno.h>
7
#include <sys/socket.h>
8
#include <netinet/in.h>
9
#include <unistd.h>
10
#include <arpa/inet.h>
11
#include <pthread.h>
12
#include <fcntl.h>
13

14
int main()
15
{
16
    int sock_fd;
17
    struct sockaddr_in seve, cli;
18

19
    sock_fd = socket(AF_INET, SOCK_STREAM, 0);
20

21
    memset(&seve, 0, sizeof(struct sockaddr_in));
22
    seve.sin_family = AF_INET;
23
    seve.sin_port = htons(4555);
24
    seve.sin_addr.s_addr = htonl(INADDR_ANY);
25

26
    bind(sock_fd, (struct sockaddr *)&seve, sizeof(struct sockaddr_in));
27

28
    if (listen(sock_fd, 5) < 0)
29
        perror("listen");
30

31
    socklen_t len = sizeof(struct sockaddr_in);
32

33
    sleep(30);
34
    printf("连接一个\n");
35
    int newfd = accept(sock_fd, (struct sockaddr *)&cli, &len);
36

37
    sleep(30);
38
    printf("连接一个\n");
39
    newfd = accept(sock_fd, (struct sockaddr *)&cli, &len);
40

41
    sleep(30);
42
    printf("连接一个\n");
43
    newfd = accept(sock_fd, (struct sockaddr *)&cli, &len);
44

45
    while (1)
46
    {
47
    }
48
}

1
// 客户端代码
2
#include <stdlib.h>
3
#include <stdio.h>
4
#include <string.h>
5
#include <sys/types.h>
6
#include <errno.h>
7
#include <sys/socket.h>
8
#include <netinet/in.h>
9
#include <unistd.h>
10
#include <arpa/inet.h>
11
#include <pthread.h>
12
#include <fcntl.h>
13

14
int main(int argc, char *argv[])
15
{
16
    int sock_fd, ret;
17
    int haha;
18
    struct sockaddr_in seve;
19
    sock_fd = socket(AF_INET, SOCK_STREAM, 0);
20
    seve.sin_family = AF_INET;
21
    seve.sin_port = htons(4555);
22
    inet_aton("127.0.0.1", &seve.sin_addr); // 所连接的局域网的ＩＰ
23
    if (connect(sock_fd, (struct sockaddr *)&seve, sizeof(struct sockaddr_in)) < 0)
24
        perror("connect");
25
    printf("连接成功\n");
26
    while (1)
27
    {
28
    }
29
}

• 两个代码在root下执行

• 监控4555端口的情况(此数据是在一台电脑下开多个终端测试)

  • 命令：watch -n 1 -d 'netstat -natp | grep "4555"'

• 因为是一个电脑开多个终端所以每一次执行客户端代码都会显示两行

• 这是最开始将打开了多个终端去连接服务器，此时正在sleep,我们可以看到ACCEPT队列里有６个内容，而我们的backlog值为５;所以我们可以得出结论backlog的值是规定==ACCEPT队列==大小的

• 当ACCEPT队列满了时后来的客户端，就会被放到ＳＹＮ队列中

• 在早期 Linux 内核 backlog 是 SYN 队列大小，也就是未完成的队列大小

• 在 Linux 内核 2.2 之后，backlog 变成 accept 队列，也就是已完成连接建立的队列长度，所以现在通常认为 backlog 是 accept 队列

• 但是上限值是内核参数 somaxconn 的大小，也就说 accpet 队列长度 = ==min(backlog, somaxconn)==

3.5.1.什么是超时重传？#

• 重传机制的一个方式，就是在发送数据时，设定一个定时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文，就会重发该数据，也就是我们常说的超时重传
• TCP 会在以下两种情况发生超时重传：
  • 数据包丢失
  • 确认应答丢失

3.5.2.什么是快速重传？#

• TCP 还有另外一种快速重传（Fast Retransmit）机制，它不以时间为驱动，而是以数据驱动重传

• 快速重传机制，是如何工作的呢？其实很简单，一图胜千言

• 在快速重传机制中，TCP在收到乱序的包后，会立马确认

• 在上图，发送方发出了 1，2，3，4，5 份数据：

  • 第一份 Seq1 先送到了，于是就 Ack 回 2；
  • 结果 Seq2 因为某些原因没收到，Seq3 到达了，于是还是 Ack 回 2；
  • 后面的 Seq4 和 Seq5 都到了，但还是 Ack 回 2，因为 Seq2 还是没有收到；
  • 发送端收到了三个 Ack = 2 的确认，知道了 Seq2 还没有收到，就会在定时器过期之前，重传丢失的 Seq2。
  • 最后，收到了 Seq2，此时因为 Seq3，Seq4，Seq5 都收到了，于是 Ack 回 6 。 所以，快速重传的工作方式是当收到三个相同的 ACK 报文时，会在定时器过期之前，重传丢失的报文段。

• 快速重传机制只解决了一个问题，就是超时时间的问题，但是它依然面临着另外一个问题。就是重传的时候，是重传一个，还是重传所有的问题。

• 举个例子，假设发送方发了 6 个数据，编号的顺序是 Seq1 ~ Seq6 ，但是 Seq2、Seq3 都丢失了，那么接收方在收到 Seq4、Seq5、Seq6 时，都是回复 ACK2 给发送方，但是发送方并不清楚这连续的 ACK2 是接收方收到哪个报文而回复的， 那是选择重传 Seq2 一个报文，还是重传 Seq2 之后已发送的所有报文呢（Seq2、Seq3、 Seq4、Seq5、 Seq6） 呢？

  • 如果只选择重传 Seq2 一个报文，那么重传的效率很低。因为对于丢失的 Seq3 报文，还得在后续收到三个重复的 ACK3 才能触发重传。
  • 如果选择重传 Seq2 之后已发送的所有报文，虽然能同时重传已丢失的 Seq2 和 Seq3 报文，但是 Seq4、Seq5、Seq6 的报文是已经被接收过了，对于重传 Seq4 ～Seq6 折部分数据相当于做了一次无用功，浪费资源。

• 可以看到，不管是重传一个报文，还是重传已发送的报文，都存在问题。

• 为了解决不知道该重传哪些 TCP 报文，于是就有 SACK 方法。

3.5.3 什么是SACK 方法？#

• 还有一种实现重传机制的方式叫：SACK（ Selective Acknowledgment）， 选择性确认。
• 这种方式需要在 TCP 头部「选项」字段里加一个 SACK 的东西，它可以将已收到的数据的信息发送给「发送方」，这样发送方就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。
• 如下图，发送方收到了三次同样的 ACK 确认报文，于是就会触发快速重发机制，通过 SACK 信息发现只有 200~299 这段数据丢失，则重发时，就只选择了这个 TCP 段进行重复。

• 如果要支持 SACK，必须双方都要支持。在 Linux 下，可以通过 net.ipv4.tcp_sack 参数打开这个功能（Linux 2.4 后默认打开）。

3.5.4.什么是Duplicate SACK？#

• Duplicate SACK 又称 D-SACK，其主要使用了 SACK 来告诉「发送方」有哪些数据被重复接收了。
• 下面举例两个栗子，来说明 D-SACK 的作用。

3.6.1.引入窗口概念的原因是什么？#

• 我们都知道 TCP 是每发送一个数据，都要进行一次确认应答。当上一个数据包收到了应答了， 再发送下一个。
• 这个模式就有点像我和你面对面聊天，你一句我一句。但这种方式的缺点是效率比较低的。
• 如果你说完一句话，我在处理其他事情，没有及时回复你，那你不是要干等着我做完其他事情后，我回复你，你才能说下一句话，很显然这不现实。

• 所以，这样的传输方式有一个缺点：数据包的往返时间越长，通信的效率就越低。
• 为解决这个问题，TCP 引入了窗口这个概念。即使在往返时间较长的情况下，它也不会降低网络通信的效率。
• 那么有了窗口，就可以指定窗口大小，窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值。
• 窗口的实现实际上是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。
• 假设窗口大小为 3 个 TCP 段，那么发送方就可以「连续发送」 3 个 TCP 段，并且中途若有 ACK 丢失，可以通过「下一个确认应答进行确认」。如下图：

• 图中的 ACK 600 确认应答报文丢失，也没关系，因为可以通过下一个确认应答进行确认，只要发送方收到了 ACK 700 确认应答，就意味着 700 之前的所有数据「接收方」都收到了。这个模式就叫累计确认或者累计应答。

3.6.2.窗口大小由哪一方决定？#

• TCP 头里有一个字段叫 Window，也就是窗口大小。
• 这个字段是==接收端==告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。
• 所以，通常窗口的大小是由接收方的窗口大小来决定的。
• 发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据。

3.6.3.发送方的滑动窗口#

• 我们先来看看发送方的窗口，下图就是发送方缓存的数据，根据处理的情况分成四个部分，其中深蓝色方框是发送窗口，紫色方框是可用窗口：

• 在图中：

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

• 在下图，当发送方把数据「全部」都一下发送出去后，可用窗口的大小就为 0 了，表明可用窗口耗尽，在没收到 ACK 确认之前是无法继续发送数据了。

• 在下图，当收到之前发送的数据 3236 字节的 ACK 确认应答后，如果发送窗口的大小没有变化，则滑动窗口往右边移动 5 个字节，因为有 5 个字节的数据被应答确认，接下来 5256 字节又变成了可用窗口，那么后续也就可以发送 52~56 这 5 个字节的数据了。

3.6.4.程序是如何表示发送方的四个部分的呢？#

• 看看就行，不是很重要

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

• 在图中：

  • SND.WND：表示发送窗口的大小（大小是由接收方指定的）；
  • SND.UNA（Send Unacknoleged）：是一个绝对指针，它指向的是已发送但未收到确认的第一个字节的序列号，也就是 #2 的第一个字节。
  • SND.NXT：也是一个绝对指针，它指向未发送但可发送范围的第一个字节的序列号，也就是 #3 的第一个字节。
  • 指向 #4 的第一个字节是个相对指针，它需要 SND.UNA 指针加上 SND.WND 大小的偏移量，就可以指向 #4 的第一个字节了。

• 那么可用窗口大小的计算就可以是：

  • 可用窗口大小 = SND.WND -（SND.NXT - SND.UNA）

3.6.5.接收方的滑动窗口#

• 接下来我们看看接收方的窗口，接收窗口相对简单一些，根据处理的情况划分成三个部分：
  • #1 + #2 是已成功接收并确认的数据（等待应用进程读取）；
  • #3 是未收到数据但可以接收的数据；
  • #4 未收到数据并不可以接收的数据；

• 其中三个接收部分，使用两个指针进行划分:
  • RCV.WND：表示接收窗口的大小，它会通告给发送方。
  • RCV.NXT：是一个指针，它指向期望从发送方发送来的下一个数据字节的序列号，也就是 #3 的第一个字节。
  • 指向 #4 的第一个字节是个相对指针，它需要 RCV.NXT 指针加上 RCV.WND 大小的偏移量，就可以指向 #4 的第一个字节了。

3.6.6.接收窗口和发送窗口的大小是相等的吗？#

• 并不是完全相等，接收窗口的大小是约等于发送窗口的大小的。
• 因为滑动窗口并不是一成不变的。比如，当接收方的应用进程读取数据的速度非常快的话，这样的话接收窗口可以很快的就空缺出来。那么新的接收窗口大小，是通过 TCP 报文中的 Windows 字段来告诉发送方。那么这个传输过程是存在时延的，所以接收窗口和发送窗口是约等于的关系。