dx1313113的博客

计算机的网卡本身具有MAC地址，并通过核对收到的包的接收方MAC地址判断是不是发给自己的，如果不是发给自己的，则丢弃；相对的，交换机的端口不核对接收方MAC地址，而是直接接受所有的包并存放到缓冲区中。浏览器会先看自身有没有对这个域名的缓存，如果有，就直接返回，如果没有，就去问操作系统，操作系统也会去看自己的缓存，如果有，就直接返回，如果没有，再去 hosts 文件看，也没有，才会去问「本地 DNS 服务器」。上下关系是有一定的规则的，上面的部分会向下面的部分委托工作，下面的部分收到委托的工作并执行。

Ping是基于工作的，ICMP报文封装在IP包里面，它工作在网络层，是IP协议的助手。

每一个路由器都可以分配很多私有地址，并且不同路由器的私有地址可以重复，通过这种地址转换，能够大大增加地址的容量。对于有Internet访问需求而内部又使用私有地址的网络，就要在组织的出口位置部署NAT网关，在报文离开私网进入Internet时，将源IP替换为公网地址，通常是出口设备的接口地址。把一个路由下的私有IP请求转换为该路由的请求，用不同的端口号来区分私有IP地址网络的主机，最终表现为该路由向服务器请求数据，接收到数据后，该路由通过端口号将数据发送给此路由下的主机。

D类和E类地址是没有主机号的，所以不可用于主机IP，D类常被用于多播，E类是预留的分类，暂时未使用。

这时，接收方的程序如果不知道发送方发送的消息长度，也就是不知道消息的边界时，是无法读出一个有效的用户消息的，因为用户消息被拆分成多个TCP报文后，并不能像UDP那样，一个UDP报文就能代表一个完整的用户消息。之所以会说TCP是面向字节流的协议，UDP是面向报文的协议，是因为操作系统对TCP和UDP协议的发送方的机制不同，也就是问题原因在发送方。当两个消息的某个部分内容被分到同一个TCP报文时，就是常说的TCP粘包问题，这时，接收方不知道消息的边界的话，是无法读出有效消息的。当用户消息通过TCP协议传输时，

TCP连接在Linux内核中是一个名为的结构体，该结构体的内容包含TCO连接的状态等信息。当拔掉网线的时候，操作系统并不会变更该结构体的任何内容，所以TCP连接的状态也不会发生改变。

可以看一下之前的一篇，里面提到过类似情况。如果两端的TCP连接一直没有数据交互，达到了触发TCP保活机制的条件，那么内核里的TCP协议栈就会发送探测报文。所以，TCP保活机制可以在双方没有数据交互的情况下，通过探测报文，来确定对方的TCP连接是否存活。

HTTP的Keep-Alive 也叫HTTP长连接，该功能是由[应用程序]实现的，可以使得同一个TCP来发送和接收多个HTTP请求/应答，减少了HTTP短连接带来的多次TCP连接建立和释放的开销。TCP的Keep-Alive也叫TCP的保活机制，该功能是由[内核]实现的，当客户端和服务端长达一定时间没有进行数据交互的时候，内核为了确保该连接是否还有效，就会发送探测报文，来检测对方是否在线，然后来决定是否要关闭该连接。

定义了一个时间段，在这个时间段内，如果没有任何连接相关的活动，TCP保活机制会开始作用，每隔一个时间间隔，发送一个探测报文，该探测报文包含的数据非常少，如果连续几个探测报文都没有得到响应，则认为当前的TCP连接已经死亡，系统内核将错误信息通知给上层应用程序。注意不是进程崩溃，进程崩溃后操作系统会在回收进程资源的时候，会发送FIN报文，而主机宕机则是无法感知的，所以需要TCP保活机制来探测对方是不是发生了主机宕机。，所以即使服务端的进程退出了，还是能与客户端完成TCP四次挥手的过程。

从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的。回顾一下四次挥手双方FIN包的过程就能理解为什么需要四次挥手了。主动关闭连接的，才有TIME_WAIT状态。一般会分开发送，因此是需要四次挥手。

因为这个第三次我收的ACK是对第二次握手SYN的确认报文，所以当第三次握手丢失了，如果服务端那一方迟迟收不到这个确认报文，就会触发超时重传机制，重传SYN-ACK报文。因为第二次握手报文里包含对客户端的第一次握手的ACK确认报文，所以，如果客户端迟迟没有收到第二次握手，那么客户端就觉得可能自己的SYN报文(第一次握手)丢失了，于是。然后，因为第二次握手中包含服务端的SYN报文，所以当客户端收到后，需要给服务端发送ACK确认报文(第三次握手)，服务端才会认为该SYN报文被客户端收到了。

当IP层有一个超过MTU大小的数据(TCP头部+TCP数据)要发送，那么IP层就要进行分片，把数据分片为若干片，保证每一个分片都小于MTU。后，接收方的IP层就无法组装成一个完整的TCP报文，也就无法将数据报文送给TCP层，所以接收方不会响应ACK给发送方，因为发送方迟迟收不到ACK确认报文，所以就会触发。网络层最常用的是IP协议，IP协议会将传输层的报文作为数据部分，再加上IP包头组装成IP报文，如果IP报文大小超过了MTU(1500字节)就会。因此，由IP层进行分片传输，是非常没有效率的。

展开第一点：假设每次建立连接，客户端恶核服务端的初始化序列号都是从0开始：可以看到，如果每次建立连接客户端和服务端的初始化序列号都不一样，就有大概率因为历史报文的序列号不在对方的接受窗口，从而很大程度上避免了历史报文如果每次建立连接客户端与服务端的初始化序列号都一样，就有很大概率遇到历史报文的序列号刚好在对方的接收窗口内，从而导致历史报文被新连接成功接收。

在数据链路层中，通过MAC地址来寻找局域网中的主机。]字段知道该数据包是TCP/UDP，所以可以根据这个信息确定送给哪个模块(TCP/UDP)处理，送给TCP/UDP模块的报文根据[因此，TCP/UDP各自的端口号也相互独立，如TCP有一个80的端口号，UDP也可以有一个80的端口号，并不冲突。]字段，而UDP头部长度是不会变化的，无需多一个字段去记录UDP的首部长度。所以，传输层的端口号的作用是为了区分同一个主机上不同应用程序的数据包。UDP不提供复杂的控制机制，利用IP提供面向[无连接]的通信服务。

TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。面向连接：一定是[一对一]才能连接，不能像UDP协议可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；可靠的：无论网络链路中出现了怎样的链路变化，TCP都可以保证一个报文一定能够到达接收端字节流：用户消息通过TCP协议传输时，消息可能会被操作系统[分组]成多个TCP报文，如果接收端不知道消息的边界，是无法读出一个有效的用户消息的。

常规回答：“因为三次握手才能保证双方具有接收和发送的能力”转存失败重新上传取消客户端连续发送多次SYN（都是同一个四元组）建立连接的报文，在上述中的「旧 SYN 报文」称为历史连接，TCP 使用三次握手建立连接的。TIP如果服务端在收到 RST 报文之前，先收到了「新 SYN 报文」，也就是服务端收到客户端报文的顺序是：「旧 SYN 报文」->「新 SYN 报文」，此时会发生什么?当服务端第一次收到 SYN 报文，也就是收到 「旧 SYN 报文」时，就会回复SYN + ACK。