面试知识点总结

就是水各大面经，然后自己总结下啦，怕忘QAQ

1.介绍一下信号量和互斥锁

信号量 互斥锁 条件变量的区别

信号量用在多线程多任务同步的，一个线程完成了某一个动作就通过信号量告诉别的线程，别的线程再进行某些动作（大家都在semtake的时候，就阻塞在哪里）。

而互斥锁是用在多线程多任务互斥的，一个线程占用了某一个资源，那么别的线程就无法访问，直到这个线程unlock，其他的线程才开始可以利用这个资源。比如对全局变量的访问，有时要加锁，操作完了，再解锁。有的时候锁和信号量会同时使用的

也就是说，信号量不一定是锁定某一个资源，而是流程上的概念，比如：有A,B两个线程，B线程要等A线程完成某一任务以后再进行自己下面的步骤，这个任务并不一定是锁定某一资源，还可以是进行一些计算或者数据处理之类。而线程互斥量则是“锁住某一资源”的概念，在锁定期间内，其他线程无法对被保护的数据进行操作。在有些情况下两者可以互换。

参考：信号量与互斥锁

信号量与互斥锁之间的区别：

1.互斥锁用于线程的互斥，信号量用于线程的同步。

互斥：是指某一资源同时只允许一个访问者对其进行访问，具有唯一性和排它性。但互斥无法限制访问者对资源的访问顺序，即访问是无序的。

同步：是指在互斥的基础上（大多数情况），通过其它机制实现访问者对资源的有序访问。在大多数情况下，同步已经实现了互斥，特别是所有写入资源的情况必定是互斥的。少数情况是指可以允许多个访问者同时访问资源

2.互斥量值只能为0/1，信号量值可以为非负整数。

一个互斥量只能用于一个资源的互斥访问，它不能实现多个资源的多线程互斥问题。信号量可以实现多个同类资源的多线程互斥和同步。当信号量为单值信号量是，也可以完成一个资源的互斥访问。

3.互斥量的加锁和解锁必须由同一线程分别对应使用，信号量可以由一个线程释放，另一个线程得到。

信号量通过一个计数器控制对共享资源的访问，信号量的值是一个非负整数，所有通过它的线程都会将该整数减一。如果计数器大于0，则访问被允许，计数器减1；如果为0，则访问被禁止，所有试图通过它的线程都将处于等待状态。

计数器计算的结果是允许访问共享资源的通行证。因此，为了访问共享资源，线程必须从信号量得到通行证， 如果该信号量的计数大于0，则此线程获得一个通行证，这将导致信号量的计数递减，否则，此线程将阻塞直到获得一个通行证为止。当此线程不再需要访问共享资源时，它释放该通行证，这导致信号量的计数递增，如果另一个线程等待通行证，则那个线程将在那时获得通行证。

Semaphore（信号量）可以被抽象为五个操作：

1.创建 Create
2.等待 Wait
线程等待信号量，如果值大于0，则获得，值减一；如果只等于0，则一直线程进入睡眠状态，知道信号量值大于0或者超时。
3.释放 Post
执行释放信号量，则值加一；如果此时有正在等待的线程，则唤醒该线程。
4.试图等待 TryWait
如果调用TryWait，线程并不真正的去获得信号量，还是检查信号量是否能够被获得，如果信号量值大于0，则TryWait返回成功；否则返回失败。
5.销毁 Destroy

Mutex（互斥量）可以被抽象为四个操作：

1.创建 Create
2.加锁 Lock
3.解锁 Unlock
4.销毁 Destroy

2.画出TCP的三次握手和四次挥手，标明每个过程数据报携带的信息

TCP的三次握手：

Establishing a normal TCP connection requires three separate steps:

1.The first host (Alice) sends the second host (Bob) a “synchronize” (SYN) message with its own sequence number x, which Bob receives.

2.Bob replies with a synchronize-acknowledgment (SYN-ACK) message with its own sequence number y and acknowledgement number x + 1, which Alice receives.

3.Alice replies with an acknowledgment message with acknowledgement number y + 1, which Bob receives and to which he doesn’t need to reply.

建立连接的过程如下图：

In this setup, the synchronize messages act as service requests from one server to the other, while the acknowledgement messages return to the requesting server to let it know the message was received.同步消息扮演了requests的角色，已接受消息是通知request server，该消息我已经收到了。

为什么要加1呢？为什么不直接传输接收到的number呢？
The reason for the client and server not using the default sequence number such as 0 for establishing connection is to protect against two incarnations of the same connection reusing the same sequence number too soon, which means a segment from an earlier incarnation of a connection might interfere with a later incarnation of the connection.为了避免前面的连接影响后面连接的可能性。

上面关于三次握手已经分析的很好了，在外网上没有找到很好的关于四次挥手的内容，这里参考简析TCP的三次握手与四次分手

多么清晰的图！

为什么需要三次握手呢？为什么不是两次呢？

为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”

为什么需要四次挥手呢？

TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。如果要正确的理解四次分手的原理，就需要了解四次分手过程中的状态变化。

注意：发送断连接请求的主机可以是客户端，也可以是服务器，谁不想发送数据了，谁就请求嘛。

下面来看看四次分手中的状态变化：

FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。（主动方）

FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。（主动方）

CLOSE_WAIT：这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。（被动方）

LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。（被动方）

TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FINWAIT1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。（主动方）注意特殊情况哦！

CLOSED: 表示连接中断。

3.关于linux的基础命令

参考我最常用的20条命令

参考：每天一个linux命令目录

whereis命令只能用于程序名的搜索，而且只搜索二进制文件（参数-b）、man说明文件（参数-m）和源代码文件（参数-s）。如果省略参数，则返回所有信息。

和find相比，whereis查找的速度非常快，这是因为linux系统会将 系统内的所有文件都记录在一个数据库文件中，当使用whereis和下面即将介绍的locate时，会从数据库中查找数据，而不是像find命令那样，通 过遍历硬盘来查找，效率自然会很高。

但是该数据库文件并不是实时更新，默认情况下时一星期更新一次，因此，我们在用whereis和locate 查找文件时，有时会找到已经被删除的数据，或者刚刚建立文件，却无法查找到，原因就是因为数据库文件没有被更新。

Linux下find命令在目录结构中搜索文件，并执行指定的操作。Linux下find命令提供了相当多的查找条件，功能很强大。由于find具有强大的功能，所以它的选项也很多，其中大部分选项都值得我们花时间来了解一下。即使系统中含有网络文件系统( NFS)，find命令在该文件系统中同样有效，只你具有相应的权限。 在运行一个非常消耗资源的find命令时，很多人都倾向于把它放在后台执行，因为遍历一个大的文件系统可能会花费很长的时间(这里是指30G字节以上的文件系统)。

crond是linux下用来周期性的执行某种任务或等待处理某些事件的一个守护进程，与windows下的计划任务类似，当安装完成操作系统后，默认会安装此服务工具，并且会自动启动crond进程，crond进程每分钟会定期检查是否有要执行的任务，如果有要执行的任务，则自动执行该任务。

Linux下的任务调度分为两类，系统任务调度和用户任务调度。

系统任务调度：系统周期性所要执行的工作，比如写缓存数据到硬盘、日志清理等。在/etc目录下有一个crontab文件，这个就是系统任务调度的配置文件。

用户任务调度：用户定期要执行的工作，比如用户数据备份、定时邮件提醒等。用户可以使用 crontab 工具来定制自己的计划任务。所有用户定义的crontab 文件都被保存在 /var/spool/cron目录中。其文件名与用户名一致。

用户所建立的crontab文件中，每一行都代表一项任务，每行的每个字段代表一项设置，它的格式共分为六个字段，前五段是时间设定段，第六段是要执行的命令段，格式如下：

minute hour day month week command

command：要执行的命令，可以是系统命令，也可以是自己编写的脚本文件。如图：

在以上各个字段中，还可以使用以下特殊字符：

星号（*）：代表所有可能的值，例如month字段如果是星号，则表示在满足其它字段的制约条件后每月都执行该命令操作。

逗号（,）：可以用逗号隔开的值指定一个列表范围，例如，“1,2,5,7,8,9”

中杠（-）：可以用整数之间的中杠表示一个整数范围，例如“2-6”表示“2,3,4,5,6”

正斜线（/）：可以用正斜线指定时间的间隔频率，例如“0-23/2”表示每两小时执行一次。同时正斜线可以和星号一起使用，例如*/10，如果用在minute字段，表示每十分钟执行一次。

4.关于HTTP Cookie

简言之，cookie是浏览器存储在用户电脑上的一些数据；每次发起请求时，浏览器都会将对应的cookie数据一起发送至服务器。

HTTP协议是无状态的，也就是说客户端和服务器端不需要建立持久的连接。由于客户端和服务器的连接是基于一种请求应答模式，及客户端和服务器建立一个连接，客户端提交一个请求，服务器端收到请求后返回一个响应，然后二者就断开连接。

cookie是有生命周期的，一旦到了cookie的失效日期，客户端的cookie就会被删除。服务器在创建cookie时可以控制一个cookie可以在客户端“存活”多长时间。在以下几种情况下，cookie都会结束它自己的生命周期：

1.未指定过期时间的cookie；当服务器创建一个cookie的时候没有指定对应的过期时间时，客户端会将这类cookie写入浏览器开辟的一块内存中，当关闭浏览器以后，这块内存也就被释放了，对应的cookie也就是结束了它的生命；可看出，默认的生命周期很短。

2.指定过期时间的cookie；当服务器创建一个cookie的时候指定了对应的过期时间时，当到达了过期时间时，对应的cookie就会被删除；

3.当浏览器中的cookie数量达到了限制时，那么浏览器就会按照某种策略删除一些旧的cookie，腾出空间来创建新的cookie；

4.可以手动删除cookie。

但是浏览器对于cookie的写入肯定是有限制的，无规矩，不成方圆啊，cookie的管理：

总之，在进行cookie操作的时候，应该尽量保证cookie个数小于20个，总大小小于4KB。

除了个数和大小的管理以外，每个站点各自的写的cookie，浏览器又如何管理呢？我们在服务器端创建一个cookie的时候，一般都会指定以下两个选项：

1.domain选项
2.path选项

这两个选项决定了创建的cookie属于哪个域名下的哪个位置。对于domain选项，默认情况下，domain会被设置为创建该cookie的页面所在的域名，所以当给相同域名发送请求时，该cookie会一起被发送至服务器。比如百度这样的大站，有很多的二级域名，例如：http://music.baidu.com/、http://picture.baidu.com/等，如果需要在所有的二级域名下都记录一个cookie，则需要在创建cookie的时候，将cookie的domain选项设置为baidu.com；此时域名为baidu.com下的所有二级域名都将拥有同样的一个cookie。创建域名时指定domain，这又是一个难点，经常会出现顶级域名和二级域名的cookie冲突问题。

我们在发送请求时，浏览器会把domain的值与请求的域名做一个尾部比较（即从字符串的尾部开始比较），并将匹配的cookie发送至服务器。

1.当我们未指定domain时，默认的domain为用哪个域名访问就是哪个。如果是顶级域名访问，那么设置的cookie也可以被其他二级域名所共享，因此登录等操作一般都在顶级域名下进行操作。

2.二级域名可以读取设置了domain为顶级域名或者自身的cookie，但是不能读取其他二级域名domain的cookie，因此想要cookie在多个二级域名中共享的时候，需要设置domain为顶级域名，这样就可以在所有二级域名里面使用该cookie，这里需要注意的是顶级域名只能获取到domain设置为顶级域名的cookie，无法获取domain设置为二级域名的cookie。

3.顶级域名的cookie在顶级域名或者二级域名都可以删除，但是非顶级域名访问的网站要删除顶级域名的cookie的时候，必须要设置获取到的cookie的domain为顶级域名，这样才能删除掉顶级域名的cookie，否则会无法删除。这里默认是删除访问的域名下对应的cookie，而不是顶级域名的那个。

举个例子来说：

1.我通过浏览器访问http://www.jellythink.com，请求到达服务器以后，我创建cookie时，指定的domain只能是www.jellythink.com、.jellythink.com或者jellythink.com

2.而当我通过浏览器访问http://picture.jellythink.com，请求到达服务器以后，我创建cookie时，指定的domain只能是picture.jellythink.com、.jellythink.com或者jellythink.com

说完domain，再来说说path选项。 在创建cookie的时候，也可以指定一个path值，path选项指定了请求的资源URL中只有在存在指定的路径时，才会发送Cookie消息头，它决定了客户端发送cookie到服务器端的匹配规则。通常是将path选项的值与请求的URL从头开始逐字符比较，如果字符匹配，则发送Cookie消息头。需要注意的是，只有在domain选项满足之后才会对path属性进行比较。path属性的默认值是发送Set-Cookie消息头所对应的URL中的path部分。

创建cookie：

服务器可以指定以下常用内容：

1.domain
2.path
3.maxage
设置浏览器何时删除cookie
4.secure
Secure字段告诉浏览器在https通道时，对Cookie进行安全加密，这样即时有黑客监听也无法获取cookie内容；默认情况下，在HTTPS连接上传输的cookie都会被自动添加上secure选项。当secure值为true时，cookie在HTTP中是无效，在HTTPS中才有效
5.httponly
HttpOnly字段告诉浏览器，只有在HTTP协议下使用，对浏览器的脚本不可见，所以跨站脚本攻击时也不会被窃取，此时JS则无法访问带有httponly的cookie

5.关于HTTP Session

Cookie机制采用的是在客户端保持状态的方案；而Session机制采用的是在服务器端保持状态的方案。Cookie的作用主要是为了解决HTTP协议无状态的问题，而Session机制则是一种在客户端与服务器之间保持状态的解决方案。

Cookie使用起来很方便，使用cookie也能完成session的工作；但是使用cookie有一个很大的弊端：

1.cookie中的所有数据在客户端可以被修改，数据非常容易被伪造，那么一些重要的数据就不能存放在cookie中，安全考虑
2.如果cookie中数据字段太多会影响传输效率，效率考虑

Session是如何工作的呢？

当用户访问到一个服务器，服务器首先检查请求中是否包含了SessionID，如果包含，按照该ID找到内存中的Session，如果没有，则创建一个Session，并生成对应的SessionID。这个SessionID是唯一的、不重复的、不容易找到规律的字符串，这个SessionID将在本次响应中返回到客户端保存，而保存这个SessionID的正是cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。

从上面可以看出，没有了session，cookie依然可以玩的好好的；但是如果没有cookie的支持，session就不能愉快的玩耍了；session需要一种能够在客户端和服务器之间进行交互时，传递SessionID的机制，我们一般都是使用cookie来完成传递SessionID的任务，但是还有一种叫做URL重写的东西，也能完成这个任务。

session共享：

集群之间Session共享的问题，具体可以看看大型网站技术架构中的一些解答。

6.linux基础命令，统计重复度

去除重复行sort file |uniq
查找非重复行sort file |uniq -u
查找重复行sort file |uniq -d
统计sort file | uniq -c

主要就是用到sort和uniq这两个命令，参考linux sort,uniq,cut,wc命令详解

uniq命令可以去除排序过的文件中的重复行，因此uniq经常和sort合用。也就是说，为了使uniq起作用，所有的重复行必须是相邻的。

cut命令可以从一个文本文件或者文本流中提取文本列。

根据下列文本的第二列计算重复度，可以使用如下命令：

//文本
for:10
for:5454
fsd:fd
fs:10
996:10
for:kf
for:914

命令：

cat ./Desktop/ff.txt | cut -d ':' -f 2 | sort | uniq -cd

输出：3 10

注意，在大多数情况下，sort和uniq是一对combo

7.进程和线程有什么区别？

一、关于进程和线程，首先从定义上理解就有所不同

1、进程是什么？
是具有一定独立功能的程序、它是系统进行资源分配和调度的一个独立单位，重点在系统调度和单独的单位，也就是说进程是可以独立运行的一段程序。
2、线程又是什么？
线程进程的一个实体，是CPU调度和分派的基本单位，他是比进程更小的能独立运行的基本单位，线程自己基本上不拥有系统资源。 在运行时，只是暂用一些计数器、寄存器和栈 。

二、他们之间的关系
1、一个线程只能属于一个进程，而一个进程可以有多个线程，但至少有一个线程（通常说的主线程）。
2、资源分配给进程，同一进程的所有线程共享该进程的所有资源。
3、线程在执行过程中，需要协作同步。不同进程的线程间要利用消息通信的办法实现同步。
4、处理机分给线程，即真正在处理机上运行的是线程。
5、线程是指进程内的一个执行单元，也是进程内的可调度实体。

三、从三个角度来剖析二者之间的区别
1、调度：线程作为调度和分配的基本单位，进程作为拥有资源的基本单位。
2、并发性：不仅进程之间可以并发执行，同一个进程的多个线程之间也可以并发执行。
3、拥有资源：进程是拥有资源的一个独立单位，线程不拥有系统资源，但可以访问隶属于进程的资源。

8.随机洗牌算法

一些随机算法，比如random，在多次实验后分布并不平均。

Fisher–Yates随机置乱算法也被称做高纳德置乱算法，通俗说就是生成一个有限集合的随机排列。Fisher-Yates随机置乱算法是无偏的，所以每个排列都是等可能的，当前使用的Fisher-Yates随机置乱算法是相当有效的，需要的时间正比于要随机置乱的数，不需要额为的存储空间开销。

算法过程：

1.需要随机置乱的n个元素的数组a
2.从0到n开始循环，循环变量为i
3.生成随机数K，K为0到n之间的随机数
4.交换i位和K位的值

9.tcp的最大连接数，tcp与udp的区别？

参考单机最大tcp连接数
参考最大连接数不再争论65535

系统用一个4四元组来唯一标识一个TCP连接：{local ip, local port,remote ip,remote port}。针对这个唯一标识来做文章。

参考tcp和udp的区别

TCP协议和UDP协议特性区别总结：
1. TCP协议在传送数据段的时候要给段标号；UDP协议不
2. TCP协议可靠；UDP协议不可靠
3. TCP协议是面向连接；UDP协议采用无连接
4. TCP协议负载较高，采用虚电路；UDP采用无连接
5. TCP协议的发送方要确认接收方是否收到数据段（3次握手协议）
6. TCP协议采用窗口技术和流控制

10.tcp如何保证可靠传输？

参考TCP可靠传输&流量控制&拥塞控制

TCP可靠传输的工作原理：

1.无差错

A发送分组M1，发送就暂停发送，等待B的确认，B收到M1就向A发送确认，A收到对M1的确认后再发送下一个分组。（若A收到连续的M1分组的确认信息，则证明M2缺失）

A只要超过一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，就重传前面发过的分组，叫超时重传。由重传计时器实现。

2.超时重传

其原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。

3.停止等待协议

优点是简单，但是信道利用率太低了。解决方法是采用连续ARQ协议，发送方维持发送窗口，每次连续发送几个分组，接收方采用累积确认，对按序到达的最后一个分组发送确认。

缺点是不能向发送方反映出接收方已经正确收到的所有分组信息，例如丢失中间的分组。

TCP 连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口。TCP 的可靠传输机制用字节的序号进行控制。TCP 所有的确认都是基于序号而不是基于报文段。

发送过的数据未收到确认之前必须保留，以便超时重传时使用。发送窗口不动(没收到确认)和前移(收到新的确认)

发送缓存用来暂时存放： 发送应用程序传送给发送方 TCP 准备发送的数据；TCP 已发送出但尚未收到确认的数据。
接收缓存用来暂时存放：按序到达的、但尚未被接收应用程序读取的数据； 不按序到达的数据。

必须强调三点：

1> A 的发送窗口并不总是和 B 的接收窗口一样大（因为有一定的时间滞后）。

2> TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。

3> TCP 要求接收方必须有累积确认的功能，这样可以减小传输开销

滑动窗口图解：

TCP拥塞控制和流量控制的差别：

1.拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能承受现有的网络负荷。

2.流量控制往往指的是点对点通信量的控制，是个端到端的问题。流量控制所要做的就是控制发送端发送数据的速率，以便使接收端来得及接受。

TCP流量控制：

所谓的流量控制就是让发送方的发送速率不要太快，让接收方来得及接受。利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。

TCP的窗口单位是字节，不是报文段，发送方的发送窗口不能超过接收方给出的接收窗口的数值。

TCP拥塞控制：

在某段时间，若对网络中的某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变化，这种情况叫做拥塞。

因特网建议标准RFC2581定义了进行拥塞控制的四种算法，即1.慢开始（Slow-start)，2.拥塞避免（Congestion Avoidance)，3.快重传（Fast Restrangsmit)和4.快恢复（Fast Recovery）。

发送报文段速率的确定，1.既要根据接收端的接收能力，2.又要从全局考虑不要使网络发生拥塞，这由接收窗口和拥塞窗口两个状态量确定。

接收窗口：接收端窗口（Reciver Window)又称通知窗口（Advertised Window),是接收端根据目前的接收缓存大小所