计算机网络

qq_29542879

于 2020-09-04 21:51:18 发布

阅读量47

点赞数

本文链接：https://blog.csdn.net/qq_29542879/article/details/107146218

版权

tcp

为什么三次握手

因为TCP传输是可靠传输，那么在进行传输数据之前就必须要确定收发数据的双方都具有收发数据的能力。而三次握手的目的：就是为了确认双方都有收发数据的能力。

如果把client看作A,把server看作B

第一次： A->B，B确定A有发消息的能力。（这个时候A并不知道B收没收到消息）

第二次： ->B && B->A，A确定B有收、发消息的能力。（此时B还不知道A有没有收到自己的消息）

第三次： A->B，B确定A有收消息的能力。（现在B能够确定已经收到了自己发的ACK消息）

为什么需要四次挥手

因为TCP是可靠的全双工连接，两次挥手只能证明一方没有数据需要发送了，但是另外一方可能还需要发送信息，两次挥手还处于半连接的状态，所以双方都需要向对方发送FIN报文，表示自己没有数据需要发送了，才是真正的关闭连接。

TCP中的7种定时器

姜姜就是姜姜 2018-09-11 11:48:42 1437 收藏 3
分类专栏：网络编程后台开发

TCP中的7种定时器：

建立连接定时器(connection-establishment timer)
重传定时器(retransmission timer)
延迟应答定时器(delayed ACK timer)
坚持定时器(persist timer)
保活定时器(keepalive timer)
FIN_WAIT_2定时器(FIN_WAIT_2 timer)
TIME_WAIT定时器 (TIME_WAIT timer, 也叫2MSL timer)
下面分别介绍一下这几种定时器：

建立连接定时器(connection-establishment timer)
顾名思义，这个定时器是在建立连接的时候使用的，我们知道， TCP建立连接需要3次握手，如下图所示：
这里写图片描述
建立连接的过程中，在发送SYN时，会启动一个定时器(默认应该是3秒)，如果SYN包丢失了，那么3秒以后会重新发送SYN包的(当然还会启动一个新的定时器，设置成6秒超时)，当然也不会一直没完没了的发SYN包，在/proc/sys/net/ipv4/tcp_syn_retries 可以设置到底要重新发送几次SYN包。

重传定时器(retransmission timer)
重传定时器在TCP发送数据时设定，在计时器超时后没有收到返回的确认ACK，发送端就会重新发送队列中需要重传的报文段。使用RTO重传计时器一般有如下规则：

当TCP发送了位于发送队列最前端的报文段后就启动这个RTO计时器；
如果队列为空则停止计时器，否则重启计时器；
当计时器超时后，TCP会重传发送队列最前端的报文段；
当一个或者多个报文段被累计确认后，这个或者这些报文段会被清除出队列
重传计时器保证了接收端能够接收到丢失的报文段，继而保证了接收端交付给接收进程的数据始终的有序完整的。因为接收端永远不会把一个失序不完整的报文段交付给接收进程。

延迟应答定时器(delayed ACK timer)
延迟应答也被成为捎带ACK，这个定时器是在延迟应答的时候使用的。为什么要延迟应答呢？延迟应答是为了提高网络传输的效率。

举例说明，比如服务端收到客户端的数据后，不是立刻回ACK给客户端，而是等一段时间(一般最大200ms)，这样如果服务端要是有数据需要发给客户端，那么这个ACK就和服务端的数据一起发给客户端了，这样比立即回给客户端一个ACK节省了一个数据包。

坚持定时器(persist timer)
我们已经知道TCP通过让接收方指明希望从发送方接收的数据字节数（即窗口大小）来进行流量控制。如果窗口大小为 0会发生什么情况呢？这将有效地阻止发送方传送数据，直到窗口变为非0为止。接收端窗口变为非0后，就会发送一个确认ACK指明需要的报文段序号以及窗口大小。

如果这个确认ACK丢失了，则双方就有可能因为等待对方而使连接终止：接收方等待接收数据（因为它已经向发送方通告了一个非0的窗口），而发送方在等待允许它继续发送数据的窗口更新。为防止这种死锁情况的发生，发送方使用一个坚持定时器 (persist timer)来周期性地向接收方查询，以便发现窗口是否已增大。这些从发送方发出的报文段称为窗口探查 (window probe)。

保活定时器(keepalive timer)
在TCP连接建立的时候指定了SO_KEEPALIVE，保活定时器才会生效。如果客户端和服务端长时间没有数据交互，那么需要保活定时器来判断是否对端还活着，但是这个其实很不实用，因为默认是2小时没有数据交互才探测，时间实在是太长了。如果你真的要确认对端是否活着，那么应该自己实现心跳包，而不是依赖于这个保活定时器。

FIN_WAIT_2定时器(FIN_WAIT_2 timer)
主动关闭的一端调用完close以后（即发FIN给被动关闭的一端，并且收到其对FIN的确认ACK）则进入FIN_WAIT_2状态。如果这个时候因为网络突然断掉、被动关闭的一段宕机等原因，导致主动关闭的一端不能收到被动关闭的一端发来的FIN，主动关闭的一段总不能一直傻等着，占着资源不撒手吧？这个时候就需要FIN_WAIT_2定时器出马了，如果在该定时器超时的时候，还是没收到被动关闭一端发来的FIN，那么不好意思，不等了，直接释放这个链接。FIN_WAIT_2定时器的时间可以从/proc/sys/net/ipv4/tcp_fin_timeout中查看和设置。

TIME_WAIT定时器 (TIME_WAIT timer, 也叫2MSL timer)
TIME_WAIT是主动关闭连接的一端最后进入的状态，而不是直接变成CLOSED的状态，为什么呢？第一个原因是万一被动关闭的一端在超时时间内没有收到最后一个ACK，则会重发最后的FIN，2MSL（报文段最大生存时间）等待时间保证了重发的FIN会被主动关闭的一段收到且重新发送最后一个ACK；另外一个原因是在2MSL等待时间时，任何迟到的报文段会被接收并丢弃，防止老的TCP连接的包在新的TCP连接里面出现。不可避免的，在这个2MSL等待时间内，不会建立同样(源IP, 源端口，目的IP，目的端口)的连接。

https://blog.csdn.net/zhengzhaoyang122/article/details/82184072#%E4%B8%83%E3%80%81%E5%BD%93%E4%BD%A0%E7%94%A8%E6%B5%8F%E8%A7%88%E5%99%A8%E6%89%93%E5%BC%80%E4%B8%80%E4%B8%AA%E9%93%BE%E6%8E%A5%E7%9A%84%E6%97%B6%E5%80%99%EF%BC%8C%E8%AE%A1%E7%AE%97%E6%9C%BA%E5%81%9A%E4%BA%86%E5%93%AA%E4%BA%9B%E5%B7%A5%E4%BD%9C%E6%AD%A5%E9%AA%A4

UDP怎么实现可靠传输
1、添加seq/ack机制，确保数据发送到对端
2、添加发送和接收缓冲区，主要是用户超时重传。
3、添加超时重传机制。

http与tcp的关系

https://blog.csdn.net/qq_40406929/article/details/85915853?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase

tls记录协议

https://blog.csdn.net/chengqiuming/article/details/83095673

DNS递归查询和迭代查询

https://www.cnblogs.com/qingdaofu/p/7399670.html

心跳包

自己实现因为tcp默认保活计时器2小时

tcp长连接对方断线

保活计时器 keep_alive
https://blog.csdn.net/chrisnotfound/article/details/80111559

icmp

ICMP协议主要用来检测网络通信故障和实现链路追踪，最典型的应用就是PING和tracerooute。

PING：

通过发送回送请求报文和回送回答报文来检测源主机到目的主机的链路是否有问题，目的地是否可达，以及通信的延迟情况。

traceroute：

通过发送探测报文来获取链路地址信息。第一个探测报文TTL为1，到达第一个路由器时，TTL减1为0所以丢掉这个探测包，同时向源主机发回ICMP时间超过报文，这时源主机就获得了第一个路由器的IP地址；接着源主机发送第二个探测报文，TTL增1为2，到达第一个路由器TTL减1为1并转发探测包到第二个路由器，这时TTL减1为0，丢掉这个探测包并向源主机发回ICMP时间超过报文，源主机就获得了第二个路由器的IP地址；以此类推，直到探测报文到达traceroute的目的地，这时源主机就获得了到目的地的每一跳路由的IP地址。