传输层总结笔记3

1.TCP头格式
有源、目的端口号，指示进行通信的两个应用进程；首部长度；
序列号，表示数据部分的第一个字节的编号；
确认号，表示希望接收到的下一个字节的编号，表明该编号之前的数据都已经被确认接收了；
控制位，
ACK表示确认号有效性
RST表示强制断开连接
SYN、FIN方别表示报文属于TCP连接建立和释放的相关报文

2.TCP协议存在的意义
TCP属于传输层协议，在进行网络通信时，处于传输层之下的网络层IP协议（只能说网络层，我印象中数据链路层也是有可靠的）只能提供不可靠的信息传输。而传输层的TCP协议可以应对在传输过程中可能出现的乱序、重复、误码等问题，提供可靠的传输。

3.什么是TCP
TCP协议是一种用于传输层进行有连接，可靠的，面向字节的传输协议。
有连接表示基于TCP协议通信的两个主机之间会建立一个虚拟的连接，只能进行一对一的通信；不能像UDP一样进行广播和组播。
可靠表示TCP协议可以处理通信过程中可能出现的乱序、重复、误码问题，包括通信报文的可靠传输
面向字节表示主机在发送报文时，可能会将应用层报文分成若干段的TCP报文段进行传输。而UDP是面向报文的，不会将应用层报文拆分，会将应用层报文变成完整的UDP用户数据报进行传输

4.如何确定一个TCP连接
需要确定源主机IP地址和源进程端口号，指明发送方的主机应用进程
还需要确定目的主机IP地址和目的进程端口号，指明接收方的主机应用进程

如果一个服务器端口监听了一个客户端，则可以建立的最多TCP连接数量：
客户端的IP数量*客户端的端口数量

5.TCP和UDP的区别，以及应用场景
TCP是面向字节有连接的可靠通信，UDP是面向报文无连接的不可靠通信
在连接方面，TCP在传输之前需要通信双方建立连接，只能进行一对一的通信；而UDP不需要建立连接直接就可以进行通信，可以进行广播和组播。
在可靠性方面，TCP可以处理在通信过程中出现的失序、重复、丢失等问题提供可靠的通信服务，同时会考虑接收方的接收能力进行流量控制，还会考虑通信信道的拥挤情况来调整发送窗口。UDP只能尽可能的提供可靠的通信服务，但不能保证报文一定能正常发给接收方，也没有流量控制和拥塞控制。
在对应用层报文处理方面，TCP可能会将报文分成若干段，每一段都加上TCP首部形成TCP报文段，而且首部的长度不是固定的包含了建立释放连接，滑动窗口传输等相关的参数。UDP不会在传输层划分应用层报文，直接加上固定长度的UDP首部就进行传输。
TCP可以提供可靠的通信，一般用于一些文件传输或者HTTP、HTTPS请求报文
UDP不限于一对一通信，一般可以用于一些多播或者组播通信

so cke t
6.为什么TCP只有首部长度，UDP只有包长度
UDP用户数据报没有首部长度是因为UDP首部长度固定，8个字节，源目标端口号，包长度，校验和
TCP没有包长度，是因为在网络层的IP数据报首部有IP首部长度和IP数据报长度，可以根据这两个数据计算出TCP报文段的长度
从这个角度看UDP的包长度是冗余的，这个问题的答案有两种说法：
（1）为了使UDP的首部凑齐4字节的整数倍，以便进行设备的硬件设计。
（2）可能早期UDP并不与IP协议配合，所以需要包长度信息。

7.TCP和UDP协议可以监听相同的端口吗
一般而言，只有TCP协议中的接收方会存在监听状态，UDP协议下的通信是不存在建立连接过程的
此问题应该是：TCP和UDP可以绑定相同的端口吗
可以，因为TCP协议和UDP协议是由内核中两个独立软件模块来实现的
端口号是用来区分主机中的不同应用进程的
对于TCP报文段和UDP用户数据报，主机会根据IP数据报首部的协议字段判断报文属于什么协议，然后会将其交给不同的软件模块进行处理，再通过端口号找到对应的应用进程。

8.多个TCP服务进程可以同时绑定一个端口号吗
或者说，一个应用进程可以同时建立多个TCP连接吗
或者说，一个端口可以同时建立多个TCP连接吗
可以，一般使用四元组信息：源IP地址，目标IP地址，源端口号，目标端口号来唯一确定一个TCP连接的，只要四元组中的任意一个元素改变就代表了一个不同的TCP连接。

9.如果已经建立了一个连接，当服务器端重启时，为什么需要等待一段时间才能再次建立连接
因为连接释放需要进行四次挥手，作为主动关闭连接的服务器端会进入一段时间的时间等待状态，此时无法进行连接的建立。
解决这个问题需要在socket编程中进行特殊设置。
socket编程时是可以读取到主机端口是否处于时间等待状态的，可以进行灵活调整连接的建立

连接释放过程：
终止等待一阶段，连接释放信息，关闭等待
确认信息
终止等待二阶段，最后确认
连接释放信息
时间等待，确认信息，关闭
等待
关闭

连接建立过程：
关闭，监听
同步已发送，连接建立信息，同步已接收
确认信息
连接，确认确认信息，连接

10.TCP的三次握手过程

但客户端需要和服务端建立连接时，
服务端会首先进入监听状态，监听某个客户端端口的信息
客户端会随机初始化一个序号，给服务端发送一条连接建立报文，同时进入同步已发送状态
服务端会在收到报文后，也随机初始化一个序号，同时将确认号设置为客户端报文序号+1，给客户端发送确认报文，并进入同步已接收状态
以上的两条报文的带有连接建立标记，不能携带应用层的报文数据
客户端在收到确认信息后会进入连接建立状态，同时给服务端发送确认信息的应答信息，序号为第一条报文序号+1，确认号为服务端报文序号+1，这条报文可以携带应用层数据
服务端在收到第三条报文后也进入连接状态
然后两端开始进行数据传输

11.在Linux系统中使用netstat -napt命令来查看连接状态
netstat系列命令
net 斯戴特 s dai te

12.为什么一定要进行三次握手，两次四次为什么不行
主要原因是为了防止滞留在通信网络中的历史连接建立请求报文被服务端接收从而建立错误的连接，避免资源浪费
次要原因就是为了同步通信双方的初始序列号，以便实现滑动窗口传输机制，保证可靠传输

如果只进行前两次握手，服务器就进入连接状态，就可能会出现一些错误，比如：
当服务器端处于监听状态时，在客户端正确的连接建立报文没到之前，之前滞留在网络中的另一个连接建立报文先被服务器端收到了，在三次握手流程中，此时服务端还不会进入连接状态，而是进入同步已接收状态，会给客户端发送确认信息，当然也不会开始传输数据。但如果只有两次握手，就会进入连接状态，并开始传输数据，但当客户端收到信息后发现这并不是其准备建立的连接，就不会接收，服务端发送的数据也就没有意义，就造成了资源浪费。

13.为什么每次建立TCP连接时需要随机初始化序号，如何随机初始化
随机初始化是基于时钟计时器来设置的，逐渐递增，到达阈值后会回绕
此外还有一个时间戳，也随时间递增，到达阈值后回绕
只有两个标志都相同的才是一个TCP建立请求报文，同时二者递增也可以反映报文的生成顺序

二者的目的都是为了区分不同时期的TCP连接四元组相同的连接请求，在现实的网络通信中，很多时候四次挥手的连接释放过程中的第四次挥手时的主动释放链接方的时间等待状态不会持续太久，以及考虑网络拥塞情况下造成的客户端超时重传，这就造成了服务端很可能会收到多条TCP连接建立请求，为了使服务端可以识别，就采用了随机的不同初始化序号来区分。

14.既然IP层有IP数据报最大长度阈值，为什么TCP还会有TCP报文段数据部分最大长度阈值

本质上其实两者的目的是相似的，一般用一个就行，都是为了实现通信过程中的分组传输
分组传输与报文传输和电路传输相对应，在尽量保证安全的同时，保证了传输速率

主要原因是IP层没有超时重传机制
超时重传机制的实现需要依靠传输层的TCP协议
如果不对TCP报文段在传输层进行分片，而在网络层由IP协议进行分片，在某个IP分片丢失时就无法组合成完整的TCP数据报，在需要重传时就需要重传整个TCP报文。在现实通信流程中，通信双方会设置合理的TCP报文段数据部分最大程度，保证在加上TCP首部，IP首部后也不会超出IP数据报最大长度阈值，也就没必要再在网络层中进行分片，同时在分片丢失时，传输层也能知道丢失的分片，直接重传这一分片就可以，避免了资源浪费。

而UDP层并不需要保证报文一定能被正确接收，没有超时重传、确认应答、流量控制、拥塞控制，所以也就不需要设置和TCP报文段数据部分最大长度一样的阈值。

15.第一次握手丢失了，会怎么样
客户端会超时重传
以Linux系统为例，当客户端一直没收到服务端的应答时，会进行超时重传。
重传的次数由内核参数控制，可以通过编程修改。
每次重传之间的时间间隔会增加，考虑通信网络的拥塞情况。
但多次重传都没有应答时，会认为服务端故障，放弃连接。

16.第二次握手丢失了，会怎么样
客户端和服务端都会超时重传
因为第二次握手是服务端对客户端第一次握手的响应，同时也期待客户端响应自己的第二次握手
这就会导致客户端收不到服务端的响应，以致于超时重传
同时，服务端也收不到客户端的响应，也会超时重传
以Linux系统为例，两者的重传次数都由内核参数控制，重传时间间隔递增

我知道自己学习的是C++，但我是纯正的计算机科班出身，本科硕士都是计算机科学与技术专业，有牢固的计算机领域基础知识、算法代码和开发语言基础，我的C++语法也是在毕业前两个月学习的，作为应届毕业生我完全接受为了工作换开发语言，也自信有这个能力和时间快速适应Java开发环境，希望贵司能考虑给我一个机会。
17.第三次握手丢失了，会怎么样
只有服务端会超时重传
服务端会因为一直收不到客户端的第三次握手，而超时重传
因为在客户端的视角，并不知道自己的应答报文丢失了，客户端已经发出了最后的应答报文，已经进入了连接
如果服务器端超时重传的信息，客户端的响应一直丢失，连接会断开

18.SYN攻击，连接链接申请攻击
当一个客户端试图与服务端建立连接时，会给服务端发送第一次握手
当服务端收到第一次握手时会将该请求对象放入半连接队列，并发出第二次握手
如果后续服务端能收到第三次握手，就将对象放入全连接队列，并建立连接
如果大量的TCP连接建立请求同时被发送到一个服务端就可能会填满半连接队列
同时又因为无法收到第三次握手而导致半连接队列始终充满，就无法建立有效连接

解决办法：
（1）扩大半连接队列容量
（2）减少超时重传次数阈值，当收不到第三次握手时，不进行太多次重传就放弃连接

19.四次挥手的流程：

以客户端主动结束连接为例，有时候也可能是服务端主动，这些释放报文不强调序号
当客户端主动准备释放连接时，会向服务端发送连接释放报文，进入终止等待一阶段
服务端收到后，向客户端发送确认信息，进入关闭等待状态
客户端收到后，进入终止等待二阶段
此时客户端将不再向服务端发送任何报文，但仍然接受服务端的报文
当服务端不需要发送报文时，就再次向客户端发送连接释放报文，并进入最后确认阶段
当客户端收到后，就给服务端发送确认报文，进入时间等待阶段，在两个报文最大生存时间后自动进入关闭状态
服务端收到后直接进入关闭状态

20.为什么一定要四次挥手
四次挥手，前两次是客户端主动申请释放连接，当其收到第二次挥手后就进入了终止等待第二阶段，此时就不会再给服务端发信息
但此时服务端可能还需要给客户端发消息，所以服务端还不能释放连接，只有当服务端也不需要发信息时，才会给客户端第三次挥手，客户端第四次挥手确认。
当服务端收到客户端的第一次挥手时如果就已经不需要再给客户端发消息了，也可以第二次第三次挥手合并发送，将四次挥手简化为三次。

21.第一次挥手丢失了
客户端超时重发，时间间隔递增直到达到最大重发次数阈值。
如果达到阈值，客户端会认为服务端故障，直接进入关闭状态。

22.第二次挥手丢失了
第二次挥手的作用服务端是响应客户端的第一次挥手，此外第三次挥手应该也是服务端主动发起的，所以服务端不会重发
只有客户端重发
如果达到阈值，客户端会认为服务端故障，直接进入关闭状态。

23.第三次挥手丢失了
当客户端收到第二次挥手后，客户端将进入终止等待第二阶段
这个阶段客户端无法给服务端发消息，只能被动等待第三次挥手，是对资源的消耗
如果第三次挥手一直丢失，客户端直接进入关闭状态
在此期间因为没有收到第三次挥手，客户端也不会第四次挥手
因此就服务端就会重发第三次挥手
服务端一直收不到第四次挥手时，也会直接进入关闭状态

24.第四次挥手丢失了
第四次挥手是对第三次挥手的响应
客户端在第四次挥手后直接进入了时间等待状态
如果服务端一直收不到第四次挥手，服务端就会重发第三次挥手
客户端收到后，客户端会再次重发第四次挥手，重置计时器（两倍最大报文生存时间）
如果一直失败
两种都会直接关闭

25.为什么时间等待状态要设置成两倍最大报文生存时间
最大报文生存时间本质上是指一个报文在网络中允许生存的最大时间
这与IP数据报的IP首部中的生存时间字段有关，该字段表示报文还可以经过几次路由转发
两倍的最大生存时间就表示，允许第四次挥手的报文丢失一次

26.为什么要有时间等待状态
（1）防止滞留在网络中的报文被下一次建立的连接接收，
复杂网络通信中同一个TCP连接很可能在断开再次被建立
（2）保证服务端能正确被关闭
例如当第四次挥手丢失时，服务端就会再次给客户端发送第三次挥手
这样在客户端收到后也会重发第四次挥手

要注意超时重传时间与时间等待状态的区别
超时重传略大于一次往返时间
时间等待状态时间是两倍最大生存时间状态

27.时间等待状态太长
能唯一确定TCP连接的就是四元组信息：源IP地址，目标IP地址，源端口号，目标端口号
当客户端处于时间等待状态，就没法继续使用原来相同的四元组建立TCP连接

28.服务器出现大量时间等待状态的原因
只有主动请求断开连接才有可能进入时间等待状态

一般与HHTP的长链接机制有关
现在的浏览器大多默认开启长链接，当建立一个TCP连接后，在一次信息传输后不会立即将连接断开，在下一次传输时继续使用
开启长连接，需要客户端和服务端都允许长连接
无论哪一方不允许，在一次连接使用完之后，服务端都会主动关闭连接，主动方都是服务端

（1）所以如果使用HTTP短连接，频繁的建立和释放TCP连接就可能时间等待状态多
（2）长连接本身是需要占用资源的，所以有一个无响应时间阈值，如果一直没有消息传递，长连接就会断开
（3）长连接的数量也有限制，超过限制的长连接会被主动关闭

29.服务器出现大量关闭等待状态的原因
关闭等待是服务器收到客户端第一次挥手之后进入的状态，同时处于服务端第三次挥手之前
也就是说作为被动关闭方，处于收到了关闭申请，但又还没有准备好关闭的状态
一般是编程代码问题，使服务端不能正常关闭连接

30.如果在连接状态下，服务端出现故障
TCP设置了保活机制
如果连接建立后一直没有信息传输，客户端就会发送探测报文
如果探测报文一直没有得到回应，就会断开连接

此外，如果只是进程崩溃，但主机没有断电，内核程序正常运行，也依然可以完成正常的四次挥手断开连接