网络相关面试题（持续更新）
1.浏览器输入www.baidu.com回车，会发生什么？
（dns过程+路由器和交换机+操作系统网络协议栈处理+web服务业务逻辑处理）
1.域名解析成IP
每个主机在网络中都是IP为标识的，IP才是主机在网络中的位置，域名只是为了方便用户记忆而已，这就要求浏览器能够识别域名并且将其转化为对应的IP地址
所以浏览器会有一个DNS缓存，其中记录了一些域名与IP的对应关系，供浏览器快速查找需要的IP。但是这个DNS缓存不可能存下所有的域名-IP地址，何况IP地址有时候还会变化，因此当在浏览器DNS缓存中没有找到的时候，就要先向DNS服务器请求域名解析，DNS域名解析时用的是UDP协议。
①客户端从浏览器中输入www.baidu.com网站网址后回车，首先浏览器会查询浏览器本身的DNS缓存，一般只有几分钟的缓存，找到了就返回域名对应的IP；如果找不到，系统就会查询本地hosts文件和本地DNS缓存信息，如果找到了，就返回域名对应IP；
②如果没有找到对应的域名解析记录，那么那么系统会把浏览器的解析请求，交给客户端本地设置的DNS服务器地址解析（称为Local DNS，LDNS），如果LDNS服务的本地缓存有对应的解析记录，就会直接返回IP地址；
③如果没有，LDNS会负责继续请求其他DNS服务器；此时就是外网的DNS服务器了，先是根域名服务器，根据浏览器得到的域名，根域名服务器看到.com，会返回.com的顶级域名服务器的ip给LDNS；然后LDNS通过顶级域名服务器的ip，找到了顶级域名服务器，.com顶级域名服务器看到了是找baidu.com一级域名服务器，就将其服务器的ip返回给LDNS；然后一层一层往下找，直到找到了www.baidu.com的DNS记录，并得到对应的IP地址，这时候LDNS会把找到的www.baidu.com的ip发送给客户端浏览器，并记录在缓存中，以便未来再次访问。
④客户端浏览器收到ip之后，就可以通过ip地址找到对应的web服务器了，即服务端主机；接下来就是三次握手建立连接了
2.与目的主机进行TCP连接（三次握手）
得到域名对应的ip地址后，也就表示可以将数据送达到目的主机了，即可以向服务器发送http请求了，但是http是应用层协议，tcp是传输层，所以发送http请求之前，开始我们常说的三次握手。Http请求是使用TCP进行传输的，可以保证可靠传输，并且有序，需要建立连接，才能进行数据传输。
3.发送和接收数据
建立连接之后，就可以发送数据了，即发送http请求
以get方法为例：
①浏览器向服务器发送get方法报文
②该get方法报文通过tcp-》ip-》mac-》网关-》目的主机
③目的主机收到数据帧，通过ip-tcp-http，http协议单元回应http协议格式封装好的HTML形式数据；
④该HTML数据通过tcp-》ip-》mac-》网关-》我的主机
⑤我的主机收到数据帧，通过ip-tcp-http-浏览器，以网页形式显式HTML
4.与目的主机断开TCP连接（四次挥手）
数据传输结束之后需要断开连接，与建立连接不同，断开连接需要多一次手，四次挥手
2. tcp三次握手，四次挥手的过程?
三次握手
1.客户端的协议栈向服务器端发送了 SYN 包，并告诉服务器端当前发送序列号 j，客户端进入 SYNC_SENT 状态；
2.服务器端的协议栈收到这个包之后，和客户端进行 ACK 应答，应答的值为 j+1，表示对 SYN 包 j 的确认，同时服务器也发送一个 SYN 包，告诉客户端当前我的发送序列号为 k，服务器端进入 SYNC_RCVD 状态；
3.客户端协议栈收到 ACK 之后，使得应用程序从 connect 调用返回，表示客户端到服务器端的单向连接建立成功，客户端的状态为 ESTABLISHED，同时客户端协议栈也会对服务器端的 SYN 包进行应答，应答数据为 k+1；
4.应答包到达服务器端后，服务器端协议栈使得 accept 阻塞调用返回，这个时候服务器端到客户端的单向连接也建立成功，服务器端也进入 ESTABLISHED 状态。
四次挥手的过程：
1.首先，一方应用程序调用 close，我们称该方为主动关闭方，该端的 TCP 发送一个 FIN 包，表示需要关闭连接。之后主动关闭方进入 FIN_WAIT_1 状态
2.接着，接收到这个 FIN 包的对端执行被动关闭。这个 FIN 由 TCP 协议栈处理，我们知道，TCP 协议栈为 FIN 包插入一个文件结束符 EOF 到接收缓冲区中，应用程序可以通过 read 调用来感知这个 FIN 包。一定要注意，这个 EOF 会被放在已排队等候的其他已接收的数据之后，这就意味着接收端应用程序需要处理这种异常情况，因为 EOF 表示在该连接上再无额外数据到达。此时，被动关闭方进入 CLOSE_WAIT 状态。
3.接下来，被动关闭方将读到这个 EOF，于是，应用程序也调用 close 关闭它的套接字，这导致它的 TCP 也发送一个 FIN 包。这样，被动关闭方将进入 LAST_ACK 状态。
4.最终，主动关闭方接收到对方的 FIN 包，并确认这个 FIN 包。主动关闭方进入 TIME_WAIT 状态，而接收到 ACK 的被动关闭方则进入 CLOSED 状态。进过 2MSL 时间之后，主动关闭方也进入 CLOSED 状态。
"每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手"
3.为什么连接的时候是三次握手，关闭的时候却是四次握手？为什么不能用两次握手进行连接？
为了实现可靠数据传输,TCP 协议的通信双⽅，都必须维护⼀个序列号.
以标识发送出去的数据包中，哪些是已经被对⽅收到的。
三次握⼿的过程即是通信双⽅相互告知序列号起始值,并确认对⽅已经收到了序列号起始值的必经步骤。
"如果只是两次握⼿， ⾄多只有连接发起⽅的起始序列号能被确认， 另⼀⽅选择的序列号则得不到确 认。"
4.为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
"只有发起连接终止的一方会进入 TIME_WAIT 状态。"
1.TIME_WAIT 的作用
1.首先，这样做是为了确保最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭。
TCP 在设计的时候，做了充分的容错性设计，比如，TCP 假设报文会出错，需要重传.
在这里，如果图中主机 1 的 ACK 报文没有传输成功，那么主机 2 就会重新发送 FIN 报文。如果主机 1 没有维护 TIME_WAIT 状态，而直接进入 CLOSED 状态。
它就失去了当前状态的上下文，只能回复一个 RST 操作，从而导致被动关闭方出现错误现在主机 1 知道自己处于 TIME_WAIT 的状态，就可以在接收到 FIN 报文之后，重新发出一个 ACK 报文，
使得主机 2 可以进入正常的 CLOSED 状态。
2.第二个理由和连接“化身”和报文迷走有关系，为了让旧连接的重复分节在网络中自然消失。
在网络中，经常会发生报文经过一段时间才能到达目的地的情况.
产生的原因是多种多样的;"如路由器重启，链路突然出现故障等。"
如果迷走报文到达时，发现 TCP 连接四元组（源 IP，源端口，目的 IP，目的端口）所代表的连接不复存在，那么很简单，这个报文自然丢弃。"考虑这样一个场景":
在原连接中断后，又重新创建了一个原连接的“**化身**”，说是化身其实是因为这个连接和原先的连接四元组完全相同，如果迷失报文经过一段时间也到达，那么这个报文会被误认为是连接“化身”的一个 TCP 分节，这样就会对 TCP 通信产生影响。
所以，TCP 就设计出了这么一个机制，经过 2MSL 这个时间，足以让两个方向上的分组都被丢弃,
使得原来连接的分组在网络中都自然消失，再出现的分组一定都是新化身所产生的。划重点，"2MSL 的时间是从主机 1 接收到 FIN 后发送 ACK 开始计时的"
如果在 TIME_WAIT 时间内，因为主机1的 ACK 没有传输到主机 2，
主机 1 又接收到了主机 2 重发的 FIN 报文，那么 2MSL 时间将重新计时.因为2MSL 的时间，目的是为了让旧连接的所有报文都能自然消亡，
现在主机1重新发送了 ACK 报文，自然需要重新计时，以便防止这个ACK 报文对新可能的连接化身造成干扰。
5.如果已经建立了tcp连接，但是客户端突然出现故障了怎么办？
TCP 协议有一个保活机制。 这个机制的原理是这样的：
定义⼀个时间段，在这个时间段内，如果没有任何连接相关的活动，TCP 保活机制会开始作⽤，每隔⼀个时间间隔，发送⼀个探测报⽂，该探测报⽂包含的数据⾮常少，如果连续⼏个探测报⽂都没有得到响应，则认为当前的TCP 连接已经死亡，系统内核将错误信息通知给上层应⽤程序。
在 Linux 内核可以有对应的参数可以设置保活时间、保活探测的次数、保活探测的时间间隔，以下都为默认值：
net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75
net.ipv4.tcp_keepalive_probes=9
tcp_keepalive_time=7200：表示保活时间是 7200 秒（2⼩时），也就 2 ⼩时内如果没有任何连接相关的活动，则会启动保活机制
tcp_keepalive_intvl=75：表示每次检测间隔 75 秒；
tcp_keepalive_probes=9：表示检测 9 次⽆响应，认为对⽅是不可达的，从⽽中断本次的连接
也就是说在 Linux 系统中，最少需要经过 2 ⼩时 11 分 15 秒才可以发现⼀个「死亡」连接。
这个时间是有点⻓的，我们也可以根据实际的需求，对以上的保活相关的参数进⾏设置。
如果开启了 TCP 保活，需要考虑以下几种情况：
第⼀种，对端程序是正常⼯作的。 当 TCP 保活的探测报⽂发送给对端, 对端会正常响应，这样 TCP 保活时间会被重置，等待下⼀个 TCP 保活时间的到来。
第⼆种，对端程序崩溃并重启。 当 TCP 保活的探测报⽂发送给对端后，对端是可以响应的，但由于没有该连接的有效信息，会产⽣⼀个 RST 报⽂，这样很快就会发现 TCP 连接已经被重置。
第三种，是对端程序崩溃，或对端由于其他原因导致报⽂不可达。 当 TCP 保活的探测报⽂发送给对端后，⽯沉⼤海，没有响应，连续几次，达到保活探测次数后，TCP 会报告该 TCP 连接已经死亡。
6.如果服务器上存在大量 CLOSE_WAIT 情况，如何处理？
close_wait是被动关闭连接是形成的，根据TCP状态机，服务器端收到客户端发送的FIN，TCP协议栈会自动发送ACK，链接进入close_wait状态。
但如果服务器端不执行socket的close()操作，状态就不能由close_wait迁移到last_ack，则系统中会存在很多close_wait状态的连接，如下图所示：
可能得原因如下：
1.关闭socket不及时：例如I/O线程被意外阻塞，或者I/O线程执行的用户自定义Task比例过高，导致I/O操作处理不及时，链路不能被及时释放。
通常，CLOSE_WAIT 状态在服务器停留时间很短，如果你发现大量的 CLOSE_WAIT 状态，那么就意味着被动关闭的一方没有及时发出 FIN 包，一般有如下几种可能
1.程序问题：如果代码层面忘记了 close 相应的 socket 连接，那么自然不会发出 FIN 包，从而导致 CLOSE_WAIT 累积；或者代码不严谨，出现死循环之类的问题，导致即便后面写了 close 也永远执行不到。
2.响应太慢或者超时设置过小：如果连接双方不和谐，一方不耐烦直接 timeout，另一方却还在忙于耗时逻辑，就会导致 close 被延后。响应太慢是首要问题，不过换个角度看，也可能是 timeout 设置过小。
7.如果服务器上存在大量 TIME_WAIT 情况，如何改善？
过多的 TIME_WAIT 的主要危害有两种：
第一是内存资源占用，这个目前看来不是太严重，基本可以忽略。
第二是对端口资源的占用，一个 TCP 连接至少消耗一个本地端口。要知道，端口资源也是有限的，一般可以开启的端口为 32768～61000 ，也可以通过net.ipv4.ip_local_port_range指定，如果 TIME_WAIT 状态过多，会导致无法创建新连接
如何优化 TIME_WAIT？
1.net.ipv4.tcp_max_tw_buckets
一个暴力的方法是通过 sysctl 命令，将系统值调小。这个值默认为 18000，当系统中处于 TIME_WAIT 的连接一旦超过这个值时，系统就会将所有的 TIME_WAIT 连接状态重置，并且只打印出警告信息。这个方法过于暴力，而且治标不治本，带来的问题远比解决的问题多，不推荐使用。
2.调低 TCP_TIMEWAIT_LEN，重新编译系统
这个方法是一个不错的方法，缺点是需要“一点”内核方面的知识，能够重新编译内核。我想这个不是大多数人能接受的方式。
3.SO_LINGER 的设置
英文单词“linger”的意思为停留，我们可以通过设置套接字选项，来设置调用 close 或者 shutdown 关闭连接时的行为。
int setsockopt(int sockfd, int level, int optname, const void *optval,socklen_t optlen);
struct linger {int l_onoff; /* 0=off, nonzero=on */int l_linger; /* linger time, POSIX specifies units as seconds */
}
设置 linger 参数有几种可能：
1.如果l_onoff为 0，那么关闭本选项。l_linger的值被忽略，这对应了默认行为，close 或 shutdown 立即返回。如果在套接字发送缓冲区中有数据残留，系统会将试着把这些数据发送出去。
2.如果l_onoff为非 0， 且l_linger值也为 0，那么调用 close 后，会立该发送一个 RST 标志给对端，该 TCP 连接将跳过四次挥手，也就跳过了 TIME_WAIT 状态，直接关闭。这种关闭的方式称为“强行关闭”。 在这种情况下，排队数据不会被发送，被动关闭方也不知道对端已经彻底断开。只有当被动关闭方正阻塞在recv()调用上时，接受到 RST 时，会立刻得到一个“connet reset by peer”的异常。
struct linger so_linger;
so_linger.l_onoff = 1;
so_linger.l_linger = 0;
setsockopt(s,SOL_SOCKET,SO_LINGER, &so_linger,sizeof(so_linger));
3.如果l_onoff为非 0， 且l_linger的值也非 0，那么调用 close 后，调用 close 的线程就将阻塞，直到数据被发送出去，或者设置的l_linger计时时间到。
8.tcp和udp对比有什么区别？分别用在哪些场景？举例说明
1.TCP⾯向连接（如打电话要先拨号建⽴连接）;
UDP是⽆连接的，即发送数据之前不需要建⽴连接。
2.TCP提供可靠的服务,通过TCP连接传送的数据,⽆差错,不丢失,不重复,且按序到达;
UDP尽最⼤努⼒交付，即不保证可靠交付。
3.Tcp通过校验和，重传控制，序号标识,滑动窗⼝、确认应答实现可靠传输。
如丢包时的重发控 制，还可以对次序乱掉的分包进⾏顺序控制。
4.UDP具有较好的实时性，⼯作效率⽐TCP⾼，适⽤于对⾼速传输和实时性有较⾼的通信或⼴播通信。
5.每⼀条TCP连接只能是点到点的;UDP⽀持⼀对⼀，⼀对多，多对⼀和多对多的交互通信。
5.TCP对系统资源要求较多，UDP对系统资源要求较少。
TCP 场景
1.远程控制（SSH）
2.File Transfer Protocol（FTP）
3.邮件（SMTP、IMAP）等
4.点对点文件传出（微信等）
UDP 场景
1.网络游戏
2.音视频传输
3.DNS
4.Ping
5.直播
模糊地带（TCP、UDP 都可以考虑）
1.HTTP（目前以 TCP 为主）
2.文件传输
总结：
1.UDP 的核心价值是灵活、轻量，构造了最小版本的传输层协议。
2.TCP 最核心的价值就是提供封装好的一套解决可靠性的优秀方案
TCP 帮助我们在确保吞吐量、延迟、丢包率的基础上，保证可靠性。 UDP 则不同，UDP 提供了最小版的实现，只支持Checksum。UDP 最核心的价值是灵活、轻量、传输速度快。
9.描述拥塞 控制的过程？
TCP 的拥塞控制就是在不堵塞，不丢包的情况下，尽量发挥带宽,TCP 的拥塞控制主要来避免两种现象，包丢失和超时重传
水管有粗细，网络有带宽，也即每秒钟能够发送多少数据；水管有长度，端到端有时延。在理想状态下，水管里面水的量 = 水管粗细 x 水管长度。对于到网络上，通道的容量 = 带宽 × 往返延迟。
如果我们设置发送窗口，使得发送但未确认的包为为通道的容量，就能够撑满整个管道。
如图所示，假设往返时间为 8s，去 4s，回 4s，每秒发送一个包，每个包 1024byte。已经过去了 8s，则 8 个包都发出去了，其中前 4 个包已经到达接收端，但是 ACK 还没有返回，不能算发送成功。5-8 后四个包还在路上，还没被接收。这个时候，整个管道正好撑满，在发送端，已发送未确认的为 8 个包，正好等于带宽，也即每秒发送 1 个包，乘以来回时间 8s。
如果我们在这个基础上再调大窗口，使得单位时间内更多的包可以发送，会出现什么现象呢？
我们来想，原来发送一个包，从一端到达另一端，假设一共经过四个设备，每个设备处理一个包时间耗费 1s，所以到达另一端需要耗费 4s，如果发送的更加快速，则单位时间内，会有更多的包到达这些中间设备，这些设备还是只能每秒处理一个包的话，多出来的包就会被丢弃，这是我们不想看到的。
这个时候，我们可以想其他的办法，例如这个四个设备本来每秒处理一个包，但是我们在这些设备上加缓存，处理不过来的在队列里面排着，这样包就不会丢失，但是缺点是会增加时延，这个缓存的包，4s 肯定到达不了接收端了，如果时延达到一定程度，就会超时重传，也是我们不想看到的。
于是 TCP 的拥塞控制主要来避免两种现象，包丢失和超时重传。一旦出现了这些现象就说明，发送速度太快了，要慢一点。但是一开始我怎么知道速度多快呢，我怎么知道应该把窗口调整到多大呢？
(1)慢启动
如果我们通过漏斗往瓶子里灌水，我们就知道，不能一桶水一下子倒进去，肯定会溅出来，要一开始慢慢的倒，然后发现总能够倒进去，就可以越倒越快。这叫作慢启动。
一条 TCP 连接开始，cwnd 设置为一个报文段，一次只能发送一个；当收到这一个确认的时候，cwnd 加一，于是一次能够发送两个；当这两个的确认到来的时候，每个确认 cwnd 加一，两个确认 cwnd 加二，于是一次能够发送四个；当这四个的确认到来的时候，每个确认 cwnd 加一，四个确认 cwnd 加四，于是一次能够发送八个。可以看出这是指数性的增长。
涨到什么时候是个头呢？有一个值 ssthresh 为 65535 个字节，当超过这个值的时候，就要小心一点了，不能倒这么快了，可能快满了，再慢下来。
每收到一个确认后，cwnd 增加 1/cwnd，我们接着上面的过程来，一次发送八个，当八个确认到来的时候，每个确认增加 1/8，八个确认一共 cwnd 增加 1，于是一次能够发送九个，变成了线性增长。
但是线性增长还是增长，还是越来越多，直到有一天，水满则溢，出现了拥塞，这时候一般就会一下子降低倒水的速度，等待溢出的水慢慢渗下去。
拥塞的一种表现形式是丢包，需要超时重传，这个时候，将 sshresh 设为 cwnd/2，将 cwnd 设为 1，重新开始慢启动。这真是一旦超时重传，马上回到解放前。但是这种方式太激进了，将一个高速的传输速度一下子停了下来，会造成网络卡顿。
（2）快速重传算法
当接收端发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速的重传，不必等待超时再重传。TCP 认为这种情况不严重，因为大部分没丢，只丢了一小部分，cwnd 减半为 cwnd/2，然后 sshthresh = cwnd，当三个包返回的时候，cwnd = sshthresh + 3，也就是没有一夜回到解放前，而是还在比较高的值，呈线性增长。
当接收端发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速的重传，不必等待超时再重传。TCP 认为这种情况不严重，因为大部分没丢，只丢了一小部分，cwnd 减半为 cwnd/2，然后 sshthresh = cwnd，当三个包返回的时候，cwnd = sshthresh + 3，也就是没有一夜回到解放前，而是还在比较高的值，呈线性增长。
就像前面说的一样，正是这种知进退，使得时延很重要的情况下，反而降低了速度。但是如果你仔细想一下，TCP 的拥塞控制主要来避免的两个现象都是有问题的。
第一个问题是丢包并不代表着通道满了，也可能是管子本来就漏水。例如公网上带宽不满也会丢包，这个时候就认为拥塞了，退缩了，其实是不对的。
第二个问题是 TCP 的拥塞控制要等到将中间设备都填充满了，才发生丢包，从而降低速度，这时候已经晚了。其实 TCP 只要填满管道就可以了，不应该接着填，直到连缓存也填满。
为了优化这两个问题，后来有了TCP BBR 拥塞算法。它企图找到一个平衡点，就是通过不断的加快发送速度，将管道填满，但是不要填满中间设备的缓存，因为这样时延会增加，在这个平衡点可以很好的达到高带宽和低时延的平衡。
10.什么是nagle算法？使用时可能会有什么坑？
Nagle算法主要是避免发送小的数据包，要求TCP连接上最多只能有一个未被确认的小分组，在该分组的确认到达之前不能发送其他的小分组。相反，TCP收集这些少量的小分组，并在确认到来时以一个分组的方式发出去。
if there is new data to sendif the window size >= MSS and available data is >= MSSsend complete MSS segment nowelseif there is unconfirmed data still in the pipeenqueue data in the buffer until an acknowledge is receivedelsesend data immediatelyend ifend if
end if
从上述算法中看出：
对于MSS的片段直接发送
如果有没有被确认的data在缓冲区内，先将待发送的数据放到buffer中直到被发送的数据被确认【最多只能有一个未被确认的小分组】
两种情况置位，就直接发送数据，实际上如果小包，但是没有未被确认的分组，就直接发送数据。
这里通过一个实验来看下Nagle算法对于发送的优化：
实验要求：Client端每次发送1个字节，将hello发送到Server端，然后server再全部发送给Client，其实要点在于Client的发送，预期的结果是：
我们虽然一个字节一个字节的发，但是在协议中使用Nagle算法，可能会有延时等待的状况，即将几个字符合成一个片段进行发送
必须是收到对方的确认之后，才能再次发送
看下实验的结果：
从图中的结果可以看出
HELLO 被分成 2个包发送了，应用层调用send 5次，由于Nagle算法，将ELLO合成一个包发送，这样大可以减少Samll packet的数量，增加TCP传输的效率
分成的2个数据包，并没有连续被发出，这也符合Nagle算法的原则，即TCP连接上最多只能有一个未被确认的小分组，等待收到ACK之后，才发第二个封包。
禁用Nagle算法:
在默认的情况下,Nagle算法是默认开启的，Nagle算法比较适用于发送方发送大批量的小数据，并且接收方作出及时回应的场合，这样可以降低包的传输个数。同时协议也要求提供一个方法给上层来禁止掉Nagle算法
当你的应用不是连续请求+应答的模型的时候，而是需要实时的单项的发送数据并及时获取响应，这种case就明显不太适合Nagle算法，明显有delay的。
linux提供了TCP_NODELAY的选项来禁用Nagle算法。
禁用方法：
setsockopt(client_fd, SOL_TCP, TCP_NODELAY,(int[]){1}, sizeof(int));
来看下禁用后同样发送Hello的实验结果
从实验结果中可以得出如下结论：
- 禁止Nagle算法，每一次send，都会组一个包进行发送，HELLO被分成5个小包分别发送
2.不用等待ACK，可以连续发送
Delay ACK and Nagle
Nagle指出Nagle算法与Delay ACK机制有共存的情况下会有一些非常糟糕的状况，比如举一个场景：PC1和PC2进行通信，PC1发数据给PC2，PC1使用Nagle算法，PC2有delay ACK机制
1. PC1发送一个数据包给PC2，PC2会先不回应，delay ACK
2. PC1再次调用send函数发送小于MSS的数据，这些数据会被保存到Buffer中，等待ACK，才能再次被发送
从上面的描述看，显然已经死锁了，PC1在等待ACK，PC2在delay ACK，那么解锁的代价就是Delay ACK的Timer到期，至少40ms[40ms~500ms不等]，也就是2种算法在通信的时候，会产生不必要的延时！
可以看下实验的图示， 9包是发送H字符到server，可以看到隔了30ms的delay ack延时才等到数据，发送一个DATA+ACK包，在这个时间段内其实也是用包发送的，但是nagle算法是要等待ACK的到来才能发包的，所以也会看到11号包要在ACK包之后。如果30ms延时仍然没有数据，就是我们上述说的那样白白的等待一个delay ack超时。
如何来解决这种问题？
其实Nagle算法本身的立意是好的，避免网络充斥着过多的小包，提高网络传输的效率，同时Delay ACK也是为了提高TCP的性能，不过二者遇到了，就比较悲剧了。其实在RFC中已经提供了一个用户级别的解决方案，即避免 write–write–read的这种写法，write–read–write–read 以及write–write–write都是OK的。假设这里有数据要发送，这个数据分为头部和数据部分，2部分发送，然后再回读响应，写法如下
1.write（header）2.write（body）3.read（response）服务器read写法如下1. read（request）2. process（request）3. write（response）
应用程序使能了Nagle算法，第一个header是一定能够发送出去的，因为前面没有带确认的数据，服务器端接收到header之后，也发现是不完全的，还会再次等待request，同时要delay ACK，再次发write的时候，发现没有ACK，也会等待ACK延迟发送。这样只能超时才能再次传输。
这个问题的产生，主要是Nagle和delay ACK 副作用以及write write read的程式造成的。一般写程序的时候不推荐这样的写法。如何解决？ 可能想到的就是上面的禁止掉Nagle算法，这也是一种办法，不过这种办法同时也会让网络充斥小包，降低效率。对于应用程序来讲，只要避免write-wirte-read的这种写法就可以避免掉问题，比如write一块去写，一次写成功，就一个包发过去了，就没有等待delay的过程了！所以写程序的时候还是要注意再注意。
11.http状态码301和302是代表什么？403和304代表什么？500，502，503，504分别代表什么？
12.HTTP中的keep-alive和TCP中keepalive又有什么区别？
(1)TCP : keepalive,保持活跃的机制
原理：
定义一个时间段，在这个时间段内，如果没有任何连接相关的活动，TCP 保活机制会开始作用，每隔一个时间间隔，发送一个探测报文，该探测报文包含的数据非常少，如果连续几个探测报文都没有得到响应，则认为当前的 TCP 连接已经死亡，系统内核将错误信息通知给上层应用程序。
上述的可定义变量，分别被称为保活时间、保活时间间隔和保活探测次数。在 Linux 系统中，这些变量分别对应 sysctl 变量net.ipv4.tcp_keepalive_time、net.ipv4.tcp_keepalive_intvl、 net.ipv4.tcp_keepalve_probes，默认设置是 7200 秒（2 小时）、75 秒和 9 次探测。
如果开启了 TCP 保活，需要考虑以下几种情况：
1.第一种，对端程序是正常工作的。当 TCP 保活的探测报文发送给对端, 对端会正常响应，这样 TCP 保活时间会被重置，等待下一个 TCP 保活时间的到来。
2.第二种，对端程序崩溃并重启。当 TCP 保活的探测报文发送给对端后，对端是可以响应的，但由于没有该连接的有效信息，会产生一个 RST 报文，这样很快就会发现 TCP 连接已经被重置。
3.第三种，是对端程序崩溃，或对端由于其他原因导致报文不可达。当 TCP 保活的探测报文发送给对端后，石沉大海，没有响应，连续几次，达到保活探测次数后，TCP 会报告该 TCP 连接已经死亡。
TCP 保活机制默认是关闭的，当我们选择打开时，可以分别在连接的两个方向上开启，也可以单独在一个方向上开启。如果开启服务器端到客户端的检测，就可以在客户端非正常断连的情况下清除在服务器端保留的“脏数据”；而开启客户端到服务器端的检测，就可以在服务器无响应的情况下，重新发起连接。
（2）区别
1、TCP连接往往就是我们广义理解上的长连接，因为它具备双端连续收发报文的能力；开启了keep-alive的HTTP连接，也是一种长连接，但是它由于协议本身的限制，服务端无法主动发起应用报文。
2、**TCP中的keepalive是用来保鲜、保活的；**HTTP中的keep-alive机制主要为了让支撑它的TCP连接活的的更久，所以通常又叫做：HTTP persistent connection（持久连接） 和 HTTP connection reuse（连接重用）。
13.https握手的过程？
14.什么是httpdns？传统dns有什么问题？
1.什么是httpdns
HTTPNDS 其实就是，不走传统的 DNS 解析，而是自己搭建基于 HTTP 协议的 DNS 服务器集群，分布在多个地点和多个运营商。
当客户端需要 DNS 解析的时候，直接通过 HTTP 协议进行请求这个服务器集群，得到就近的地址
2.传统dns有什么问题？
2.1 域名缓存问题‘
它可以在本地做一个缓存，也就是说，不是每一个请求，它都会去访问权威 DNS 服务器，而是访问过一次就把结果缓存到自己本地，当其他人来问的时候，直接就返回这个缓存数据。
这就相当于导游去过一个饭店，自己脑子记住了地址，当有一个游客问的时候，他就凭记忆回答了，不用再去查地址簿。这样经常存在的一个问题是，人家那个饭店明明都已经搬了，结果作为导游，他并没有刷新这个缓存，结果你辛辛苦苦到了这个地点，发现饭店已经变成了服装店，你是不是会非常失望？
另外，有的运营商会把一些静态页面，缓存到本运营商的服务器内，这样用户请求的时候，就不用跨运营商进行访问，这样既加快了速度，也减少了运营商之间流量计算的成本。在域名解析的时候，不会将用户导向真正的网站，而是指向这个缓存的服务器。
很多情况下是看不出问题的，但是当页面更新，用户会访问到老的页面，问题就出来了。例如，你听说一个餐馆推出了一个新菜，你想去尝一下。结果导游告诉你，在这里吃也是一样的。有的游客会觉得没问题，但是对于想尝试新菜的人来说，如果导游说带你去，但其实并没有吃到新菜，你是不是也会非常失望呢？
再就是本地的缓存，往往使得全局负载均衡失败，因为上次进行缓存的时候，缓存中的地址不一定是这次访问离客户最近的地方，如果把这个地址返回给客户，那肯定就会绕远路。
就像上一次客户要吃西湖醋鱼的事，导游知道西湖边有一家，因为当时游客就在西湖边，可是，下一次客户在灵隐寺，想吃西湖醋鱼的时候，导游还指向西湖边的那一家，那这就绕的太远了。
2.2 域名转发问题
缓存问题还是说本地域名解析服务，还是会去权威 DNS 服务器中查找，只不过不是每次都要查找。可以说这还是大导游、大中介。还有一些小导游、小中介，有了请求之后，直接转发给其他运营商去做解析，自己只是外包了出去。
这样的问题是，如果是 A 运营商的客户，访问自己运营商的 DNS 服务器，如果 A 运营商去权威 DNS 服务器查询的话，权威 DNS 服务器知道你是 A 运营商的，就返回给一个部署在 A 运营商的网站地址，这样针对相同运营商的访问，速度就会快很多。
但是 A 运营商偷懒，将解析的请求转发给 B 运营商，B 运营商去权威 DNS 服务器查询的话，权威服务器会误认为，你是 B 运营商的，那就返回给你一个在 B 运营商的网站地址吧，结果客户的每次访问都要跨运营商，速度就会很慢。
2.3 出口 NAT 问题
网关在出口的时候，很多机房都会配置NAT，也即网络地址转换，使得从这个网关出去的包，都换成新的 IP 地址，当然请求返回的时候，在这个网关，再将 IP 地址转换回去，所以对于访问来说是没有任何问题。
但是一旦做了网络地址的转换，权威的 DNS 服务器，就没办法通过这个地址，来判断客户到底是来自哪个运营商，而且极有可能因为转换过后的地址，误判运营商，导致跨运营商的访问。
2.4域名更新问题
本地 DNS 服务器是由不同地区、不同运营商独立部署的。对域名解析缓存的处理上，实现策略也有区别，有的会偷懒，忽略域名解析结果的 TTL 时间限制，在权威 DNS 服务器解析变更的时候，解析结果在全网生效的周期非常漫长。但是有的时候，在 DNS 的切换中，场景对生效时间要求比较高。
例如双机房部署的时候，跨机房的负载均衡和容灾多使用 DNS 来做。当一个机房出问题之后，需要修改权威 DNS，将域名指向新的 IP 地址，但是如果更新太慢，那很多用户都会出现访问异常。
这就像，有的导游比较勤快、敬业，时时刻刻关注酒店、餐馆、交通的变化，问他的时候，往往会得到最新情况。有的导游懒一些，8 年前背的导游词就没换过，问他的时候，指的路往往就是错的。
2.5解析延迟问题
DNS 的查询过程需要递归遍历多个 DNS 服务器，才能获得最终的解析结果，这会带来一定的时延，甚至会解析超时。
15.开放性问题：从网络角度，如何优化性能？
网络相关面试题（持续更新）相关推荐
- Windows11 Android开发相关记录（持续更新...）
Windows11 Android开发相关记录(持续更新-) 本章节主要记录安装好Windos系统后开发环境搭建及其心得. 以及开发常用软件和相关配置. 以下属于个人做法,仅供参考: 文章目录 Win ...
- php 面试题 - 持续更新
面试题 推荐一个面试题github的地址!非博主 php 1. php的require和include的区别 require和include都是引入文件的方法,区别在于require引入文件失败会报错 ...
- 工作中用到的git的相关操作（持续更新）
目录 1. Git 简介 2. 鼠标右键 Git 选项含义: 3. 用 HTTP 的方式操作 github(提交时需要输入账号密码) (1) 在 github 中复制 HTTPS 链接 (2) 克隆项 ...
- 鄙人分享的一些编程相关资源（持续更新，值得收藏）
持续更新!!!(第14次更新) 一.Java 1.WEB篇 JavaWeb第一阶段(前端) JavaWeb第二阶段(J2EE) JavaWeb第三阶段(J2EE项目) JavaWeb第四阶段(交互) ...
- Linux命令 安装升级相关命令(一) (持续更新)
Linux命令常用命令持续更新 声明:本人菜鸟一枚,系统是ubuntu22.04,资料均是在网上和书上收集的.如有不对的地方,勿喷,欢迎大佬指出． sudo apt-get update 更新命令 a ...
- 前端javaScript高频面试题——持续更新
目录 1.== 和 ===区别,分别在什么情况使用 2. 判断数据类型的方法 3.说说JavaScript中的数据类型?存储上的差别? 4.JavaScript中的操作符 5.var,let,cons ...
- 前端网络知识目录（持续更新）
这里收录了前端新手进阶学习网络相关的资源链接,按照一定的先后顺序排列.如果你是新手,可以按照目录中的排序一篇一篇的看.如果你是有经验的老手,也可以选择性的浏览. 1.TCP与UDP UDP与TCP 文 ...
- Redis 知识点和面试题(持续更新ing)
推荐 书籍 <Redis实战>,<Redis设计与实现>,<Redis使用手册> 视频 [[趣话Redis第二弹]Redis数据持久化AOF和RDB原理一次搞懂!- ...
- java史上最全面试题--持续更新中（一）
1.面向对象的特征有哪些方面? 抽象:将同类对象的共同特征提取出来构造类. 继承:基于基类创建新类. 封装:将数据隐藏起来,对数据的访问只能通过特定接口. 多态性:不同子类型对象对相同消息作出不同响应 ...
最新文章
- Step-By-Step在AIX上安装Oracle RAC
- python测试开发自学教程-自动化平台测试开发：Python测试开发实战_PDF电子书
- Android Message 及其使用
- ${}和#{}的区别
- pythonturtle怎么写_让Python的turtle命令更简短(译)
- .NET Core WebApi中实现多态数据绑定
- 帝国cms listinfo.php,帝国CMS动态列表应用之在列表中显示指定的会员组会员发布的信息...
- ubuntu安装cuda（转精华）
- access 导入 txt sql语句_从零开始学 MySQL - 数据库的导入导出和备份
- 区间dp讲解之石子合并问题 区间dp的分析方法
- Android音视频开发学习笔记
- 第一个web项目-微信小程序后端开发
- PHP家庭账单系统,家庭财务管理系统1.0【PHP版】
- python转义字符\r的使用
- 时尚亲民的发烧耳机，无需焊接的模块化设计，小蝙蝠M0体验
- 计算机网络丢包排查,ping命令图文教程，电脑测试网络丢包延迟，检测网络故障通不通...
- jQuery小游戏——小鸟飞行闪躲
- 照片也能动起来，Python这个开源项目厉害了！
- WIN10提示没有默认的邮件客户端，或者当前的邮件客户端无法实现该请求，请将outlook设为默认邮件客户端“
- mysql 主从ppt_mysql主从配置