smart_an的专栏

首先，这是个IPV4地址。IPV4地址有32位，一个字节有8位，共4个字节。其中127 开头的都属于回环地址，也是IPV4的特殊地址，没什么道理，就是人为规定的。而127.0.0.1是众多回环地址中的一个。之所以不是127.0.0.2，而是127.0.0.1，是因为源码里就是这么定义的，也没什么道理。IPv4的地址是32位的，2的32次方，大概是40+亿。地球光人口就76亿了，40亿IP这点量，塞牙缝都不够，实际上IP也确实用完了。所以就有了IPV6IPv6的地址是128位的，大概是2的128次方≈。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！在日常生活或工作中，我们在判断与对方，使用的最多的莫过于ping命令了。ping” —— 来自小林的灵魂拷问可能有的小伙伴奇怪的问：“我虽然不明白它的工作，但 ping 我也用的贼 6 啊！你用的是 6 ，但你在面试官面前，你就 6 不起来了，毕竟他们也爱问。所以，我们要抱有「

如上图中的蓝色部分。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！之前回答了很多人的问题，我发现很多人对 TCP 序列号和确认号的变化都是懵懵懂懂的，只知道三次握手和四次挥手过程中，ACK 报文中确认号要 +1，然后数据传输中 TCP 序列号和确认号的变化就不知道了。也有很多同学跟我反馈，希望我写一篇关于 TCP 序列号和确认号变化过程的文章。

当被动关闭方在 TCP 挥手过程中，如果「没有数据要发送」，同时「没有开启 TCP_QUICKACK（默认情况就是没有开启，没有开启 TCP_QUICKACK，等于就是在使用 TCP 延迟确认机制）」，那么第二和第三次挥手就会合并传输，这样就出现了三次挥手。所以，出现三次挥手现象，是因为 TCP 延迟确认机制导致的。

数据从发送端到接收端，链路很长，任何一个地方都可能发生丢包，几乎可以说丢包不可避免。平时没事也不用关注丢包，大部分时候TCP的重传机制保证了消息可靠性。当你发现服务异常的时候，比如接口延时很高，总是失败的时候，可以用ping或者mtr命令看下是不是中间链路发生了丢包。TCP只保证传输层的消息可靠性，并不保证应用层的消息可靠性。如果我们还想保证应用层的消息可靠性，就需要应用层自己去实现逻辑做保证。

每一个socket执行listen时，内核都会自动创建一个半连接队列和全连接队列。第三次握手前，TCP连接会放在半连接队列中，直到第三次握手到来，才会被放到全连接队列中。accept方法只是为了从全连接队列中拿出一条连接，本身跟三次握手几乎毫无关系。出于效率考虑，虽然都叫队列，但半连接队列其实被设计成了哈希表，而全连接队列本质是链表。全连接队列满了，再来第三次握手也会丢弃，此时如果，还会直接发RST给客户端。半连接队列满了，可能是因为受到了SYN Flood攻击，可以设置，绕开半连接队列。

TCP 同时打开的情况也类似，只不过从一个客户端变成了两个客户端而已。做个实验。

TCP 和 UDP 可以同时绑定相同的端口吗？可以的。TCP 和 UDP 传输协议，在内核中是由两个完全独立的软件模块实现的。当主机收到数据包后，可以在 IP 包头的「协议号」字段知道该数据包是 TCP/UDP，所以可以根据这个信息确定送给哪个模块（TCP/UDP）处理，送给 TCP/UDP 模块的报文根据「端口号」确定送给哪个应用程序处理。因此， TCP/UDP 各自的端口号也相互独立，互不影响。多个 TCP 服务进程可以同时绑定同一个端口吗？

TCP 队头阻塞的问题要从两个角度看，一个是发送窗口的队头阻塞，另外一个是接收窗口的队头阻塞。1、发送窗口的队头阻塞。TCP 发送出去的数据，都是需要按序确认的，只有在数据都被按顺序确认完后，发送窗口才会往前滑动。举个例子，比如下图的发送方把发送窗口内的数据全部都发出去了，可用窗口的大小就为 0 了，表明可用窗口耗尽，在没收到 ACK 确认之前是无法继续发送数据了。接着，当发送方收到对第32~36字节的 ACK 确认应答后，则滑动窗口往右边移动 5 个字节，因为有 5 个字节的数据被应答确认。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！写的多了后，忽然思考一个问题，TCP 通过序列号、确认应答、超时重传、流量控制、拥塞控制等方式实现了可靠传输，看起来它很完美，事实真的是这样吗？TCP 就没什么缺陷吗？所以，今天就跟大家聊聊，TCP 协议有哪些缺陷？接下来，针对这四个方面详细说一下。

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

最后做个总结。「HTTPS 是先进行 TCP 三次握手，再进行 TLSv1.2 四次握手」，这句话一点问题都没有，怀疑这句话是错的人，才有问题。「HTTPS 中的 TLS 握手过程可以同时进行三次握手」，这个场景是可能存在到，但是在没有说任何前提条件，而说这句话就等于耍流氓。客户端和服务端都开启了 TCP Fast Open 功能，且 TLS 版本是 1.3；客户端和服务端已经完成过一次通信；怎么样，那位“面试官”学废了吗？

TCP 四次挥手过程，如下图：图片客户端打算关闭连接，此时会发送一个 TCP 首部FIN标志位被置为1的报文，也即FIN报文，之后客户端进入FIN_WAIT_1状态。服务端收到该报文后，就向客户端发送ACK应答报文，接着服务端进入状态。客户端收到服务端的ACK应答报文后，之后进入FIN_WAIT_2状态。等待服务端处理完数据后，也向客户端发送FIN报文，之后服务端进入LAST_ACK状态。客户端收到服务端的FIN报文后，回一个ACK应答报文，之后进入TIME_WAIT状态服务器收到了。

客户端拔掉网线后，并不会直接影响 TCP 连接状态。所以，拔掉网线后，TCP 连接是否还会存在，关键要看拔掉网线之后，有没有进行数据传输。在客户端拔掉网线后，如果服务端发送了数据报文，那么在服务端重传次数没有达到最大值之前，客户端就插回了网线，那么双方原本的 TCP 连接还是能正常存在，就好像什么事情都没有发生。在客户端拔掉网线后，如果服务端发送了数据报文，在客户端插回网线之前，服务端重传次数达到了最大值时，服务端就会断开 TCP 连接。

如果「客户端进程崩溃」，客户端的进程在发生崩溃的时候，内核会发送 FIN 报文，与服务端进行四次挥手。但是，「客户端主机宕机」，那么是不会发生四次挥手的，具体后续会发生什么？还要看服务端会不会发送数据？如果服务端会发送数据，由于客户端已经不存在，收不到数据报文的响应报文，服务端的数据报文会超时重传，当重传总间隔时长达到一定阈值（内核会根据 tcp_retries2 设置的值计算出一个阈值）后，会断开 TCP 连接；如果服务端一直不会发送数据，再看服务端有没有开启 TCP keepalive 机制？

在 TCP 正常挥手过程中，处于 TIME_WAIT 状态的连接，收到相同四元组的 SYN 后会发生什么？如果客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要大并且SYN 的「时间戳」比服务端「最后收到的报文的时间戳」要大。那么就会重用该四元组连接，跳过 2MSL 而转变为 SYN_RECV 状态，接着就能进行建立连接过程。如果客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要小或者SYN 的「时间戳」比服务端「最后收到的报文的时间戳」要小。那么就会。

不得不说，鹅厂真的很喜欢问网络问题，而且爱问异常情况下的网络问题不过这道鹅厂的网络题可能是提问的读者表述有问题，。因此，我们要关注到点是看「我也画了一张图，大家可以结合着图来理解。

要伪造一个能关闭 TCP 连接的 RST 报文，必须同时满足「四元组相同」和「序列号是对方期望的」这两个条件。今天给大家介绍了两种关闭 TCP 连接的工具：tcpkill 和 killcx 工具。这两种工具都是通过伪造 RST 报文来关闭 TCP 连接的，但是它们获取「对方下一次期望收到的序列号的方式是不同的，也正因此，造就了这两个工具的应用场景有区别。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！之前有个读者在秋招面试的时候，被问了这么一个问题：SYN 报文什么时候情况下会被丢弃？好家伙，现在面试都问那么细节了吗？

使用时间戳选项能够有效的防止上述问题，如果丢失的报文会在时刻 F 重新出现，由于它的时间戳为 2，小于最近的有效时间戳（5 或 6），因此防回绕序列号算法（PAWS）会将其丢弃。懂了，客户端和服务端的初始化序列号都是随机生成，能很大程度上避免历史报文被下一个相同四元组的连接接收，然后又引入时间戳的机制，从而完全避免了历史报文被接收的问题。相反，如果每次建立连接客户端和服务端的初始化序列号都「一样」，就有大概率遇到历史报文的序列号刚「好在」对方的接收窗口内，从而导致历史报文被新连接成功接收。

我们可以自定义一个消息结构，由包头和数据组成，其中包头包是固定大小的，而且包头里有一个字段来说明紧随其后的数据有多大。比如这个消息结构体，首先 4 个字节大小的变量来表示数据长度，真正的数据则在后面。当接收方接收到包头的大小（比如 4 个字节）后，就解析包头的内容，于是就可以知道数据的长度，然后接下来就继续读取数据，直到读满数据的长度，就可以组装成一个完整到用户消息来处理了。

当进程调用了。

半连接队列，也称 SYN 队列；全连接队列，也称 accept 队列；服务端收到客户端发起的 SYN 请求后，内核会把该连接存储到半连接队列，并向客户端响应 SYN+ACK，接着客户端会返回 ACK，服务端收到第三次握手的 ACK 后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到 accept 队列，等待进程调用 accept 函数时把连接取出来。不管是半连接队列还是全连接队列，都有最大长度限制，超过限制时，内核会直接丢弃，或返回 RST 包。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！为了让大家更容易「看得见」 TCP，我搭建不少测试环境，并且数据包抓很多次，花费了不少时间，才抓到比较容易分析的数据包。接下来丢包、乱序、超时重传、快速重传、选择性确认、流量控制等等 TCP 的特性，都能「一览无余」。没错，我把 TCP 的"衣服扒光"了，就为了给大家看的清楚，嘻嘻。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！TCP，它为了保证可靠性，用了巨多的机制来保证，真是个「伟大」的协议，写着写着发现这水太深了。。。本文的全部图片都是小林绘画的，非常的辛苦且累，不废话了，直接进入正文，Go！相信大家都知道 TCP 是一个可靠传输的协议，那它是如何保证可靠的呢？

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

TCP 协议本身是全双工的，但我们最常用的 HTTP/1.1，虽然是基于 TCP 的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，都不太友好，因此我们需要使用支持全双工的 WebSocket 协议。在 HTTP/1.1 里，只要客户端不问，服务端就不答。基于这样的特点，对于登录页面这样的简单场景，可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。对于客户端和服务端之间需要频繁交互的复杂场景，比如网页游戏，都可以考虑使用 WebSocket 协议。

纯裸 TCP 是能收发数据，但它是个无边界的数据流，上层需要定义消息格式用于定义消息边界。于是就有了各种协议，HTTP 和各类 RPC 协议就是在 TCP 之上定义的应用层协议。RPC 本质上不算是协议，而是一种调用方式，而像 gRPC 和 Thrift 这样的具体实现，才是协议，它们是实现了 RPC 调用的协议。目的是希望程序员能像调用本地方法那样去调用远端的服务方法。同时 RPC 有很多种实现方式，不一定非得基于 TCP 协议。从发展历史来说，

队头阻塞，HTTP/2 多个请求跑在一个 TCP 连接中，如果序列号较低的 TCP 段在网络传输中丢失了，即使序列号较高的 TCP 段已经被接收了，应用层也无法从内核中读取到这部分数据，从 HTTP 视角看，就是多个请求被阻塞了；TCP 和 TLS 握手时延，TCP 三次握手和 TLS 四次握手，共有 3-RTT 的时延；连接迁移需要重新连接。

HTTP/2 协议其实还有很多内容，比如流控制、流状态、依赖关系等等。这次主要介绍了关于 HTTP/2 是如何提升性能的几个方向，它相比 HTTP/1 大大提高了传输效率、吞吐能力。第一点，对于常见的 HTTP 头部通过静态表和 Huffman 编码的方式，将体积压缩了近一半，而且针对后续的请求头部，还可以建立动态表，将体积压缩近 90%，大大提高了编码效率，同时节约了带宽资源。

对于硬件优化的方向，因为 HTTPS 是属于计算密集型，应该选择计算力更强的 CPU，而且最好选择支持 AES-NI 特性的 CPU，这个特性可以在硬件级别优化 AES 对称加密算法，加快应用数据的加解密。对于软件优化的方向，如果可以，把软件升级成较新的版本，比如将 Linux 内核 2.X 升级成 4.X，将 openssl 1.0.1 升级到 1.1.1，因为新版本的软件不仅会提供新的特性，而且还会修复老版本的问题。密钥交换算法应该选择ECDHE 算法。

RSA 密钥协商算法「不支持」前向保密，ECDHE 密钥协商算法「支持」前向保密；使用了 RSA 密钥协商算法，TLS 完成四次握手后，才能进行应用数据传输，而对于 ECDHE 算法，客户端可以不用等服务端的最后一次 TLS 握手，就可以提前发出加密的 HTTP 数据，节省了一个消息的往返时间（这个是 RFC 文档规定的，具体原因文档没有说明，所以这点我也不太明白）；

， 一般 WITH 单词前面有两个单词，第一个单词是约定密钥交换的算法，第二个单词是约定证书的验证算法。

这次主要从 3 个方面介绍了优化 HTTP/1.1 协议的思路。第一个思路是，通过缓存技术来避免发送 HTTP 请求。客户端收到第一个请求的响应后，可以将其缓存在本地磁盘，下次请求的时候，如果缓存没过期，就直接读取本地缓存的响应数据。如果缓存过期，客户端发送请求的时候带上响应数据的摘要，服务器比对后发现资源没有变化，就发出不带包体的 304 响应，告诉客户端缓存的响应仍然有效。将原本由客户端处理的重定向请求，交给代理服务器处理，这样可以减少重定向请求的次数；

强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。如下图中，返回的是 200 状态码，但在 size 项中标识的是 from disk cache，就是使用了强制缓存。， 是一个相对时间；Expires，是一个绝对时间；如果 HTTP 响应头部同时有 Cache-Control 和 Expires 字段的话，Cache-Control 的优先级高于 Expires。

电脑与电脑之间通常都是通过网卡、交换机、路由器等网络设备连接到一起，那由于网络设备的异构性，国际标准化组织定义了一个七层的 OSI 网络模型，但是这个模型由于比较复杂，实际应用中并没有采用，而是采用了更为简化的 TCP/IP 模型，Linux 网络协议栈就是按照了该模型来实现的。TCP/IP 模型主要分为应用层、传输层、网络层、网络接口层四层，每一层负责的职责都不同，这也是 Linux 网络协议栈主要构成部分。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！想必不少小伙伴面试过程中，会遇到「」的面试题。还别说，这问题真挺常问的，前几天坐在我旁边的主管电话面试应聘者的时候，也问了这个问题。接下来以下图较简单的网络拓扑模型作为例子，探究探究其间发生了什么？

综上所述，TCP/IP 网络通常是由上到下分成 4 层，分别是应用层，传输层，网络层和网络接口层。再给大家贴一下每一层的封装格式：网络接口层的传输单位是帧（frame），IP 层的传输单位是包（packet），TCP 层的传输单位是段（segment），HTTP 的传输单位则是消息或报文（message）。但这些名词并没有什么本质的区分，可以统称为数据包。