小猿的某同事不甘于现状，近期到处投简历面试。某天，小猿只见某灰头土脸、唉声叹气，于是小猿本着看热闹不嫌事儿大的心态，一脸坏笑凑上去问：“大佬，最近面试咋样，是不是都拿好几个offer了~^_^”，某答道：“什么呀，面个试咋就这么难，一道面试题硬是让面试官扯出了整个计算机网络知识图谱，也是没谁了~”，小猿好奇问：“啥题，啥题~”，某答：“烂大街的一道题，面试前也准备了，唉，你说为啥面试官就能从这道题目扯出一堆题目...”(此处省略一万字)
接下来小猿就给大家说说某遇到的这道题，还有它牵扯出的整个计算机网络的知识图谱。废话不多说，直接上题目
题目描述一：请说说HTTP请求的整个过程
题目描述二：当你在浏览器中输出某个URL，按下回车后都经历了什么样的流程
题目描述三：请简单介绍一下HTTP是怎么工作的
相信各位猿对这道题应该并不陌生，而且网上一搜一堆的讲解与答案，但是某遇到的这个大牛面试官，却可以从某的回答中延伸出更多的问题，如果想要过关，还是要对整个计算机网络的知识体系有比较深刻的理解才行。下面先贴出小猿对这个题目的理解和可能从这道题目引出的计算机网络的知识点，然后小猿对这些知识点慢慢的给大家分析。
小猿对题目的理解：
DNS解析：如果URL中是网址，需要向对这个网址进行域名解析，得到相应的IP地址
TCP连接：根据IP，找到对应的服务器，通过TCP的三次握手建立连接
发送HTTP请求：建立TCP连接后发起HTTP请求
服务器处理请求并返回HTTP报文：服务器根据请求参数得到返回结果，并返回HTTP报文
浏览器解析渲染页面：浏览器得到报文，解析HTML代码，并请求HTML代码中的资源（例如js、css等），然后渲染页面
连接结束：TCP4次挥手，HTTP断开连接
知识图谱
OSI七层架构
七层结构简介：
7层结构数据传输流程：
详细介绍每层的功能和
应用层（Application Layer）
是计算机用户，以及各种应用程序和网络之间的接口：
是用户与网络，以及应用程序与网络间的直接接口，使得用户能够与网络进行交互式联系。
实现各种服务：该层具有的各种应用程序可以完成和实现用户请求的各种服务。
该层还负责协调各个应用程序间的工作。
应用层为用户提供的服务和协议有：文件服务、目录服务、文件传输服务（FTP）、远程登录服务（Telnet）、电子邮件服务（E-mail）、打印服务、安全服务、网络管理服务、数据库服务等。
表示层（Presentation Layer）
对来自应用层的命令和数据进行解释，对各种语法赋予相应的含义，并按照一定的格式传送给会话层。
主要功能：数据格式处理、编码、压缩解压、加密解密等，具体说明如下：
数据格式处理：协商和建立数据交换的格式，解决各应用程序之间在数据格式表示上的差异。
数据的编码：处理字符集和数字的转换。例如由于用户程序中的数据类型（整型或实型、有符号或无符号等）、用户标识等都可以有不同的表示方式，因此，在设备之间需要具有在不同字符集或格式之间转换的功能。
压缩和解压缩：为了减少数据的传输量，这一层还负责数据的压缩与恢复。
数据的加密和解密：可以提高网络的安全性。
会话层（Session Layer）
其任务就是组织和协调两个会话进程之间的通信，并对数据交换进行管理，具体如下：
会话管理：允许用户在两个实体设备之间建立、维持和终止会话，并支持它们之间的数据交换。例如提供单方向会话或双向同时会话，并管理会话中的发送顺序，以及会话所占用时间的长短。
会话流量控制：提供会话流量控制和交叉会话功能。
寻址：使用远程地址建立会话连接。
出错控制：从逻辑上讲会话层主要负责数据交换的建立、保持和终止，但实际的工作却是接收来自传输层的数据，并负责纠正错误。会话控制和远程过程调用均属于这一层的功能。但应注意，此层检查的错误不是通信介质的错误，而是磁盘空间、打印机缺纸等类型的高级错误。
传输层（Transport Layer）
向用户提供可靠的端到端的差错和流量控制，保证报文的正确传输。传输层的作用是向高层屏蔽下层数据通信的细节，即向用户透明地传送报文。
传输连接管理：提供建立、维护和拆除传输连接的功能。传输层在网络层的基础上为高层提供“面向连接”和“面向无接连”的两种服务。
处理传输差错：提供可靠的“面向连接”和不太可靠的“面向无连接”的数据传输服务、差错控制和流量控制。在提供“面向连接”服务时，通过这一层传输的数据将由目标设备确认，如果在指定的时间内未收到确认信息，数据将被重发。
监控服务质量。
该层常见的协议：TCP/IP中的TCP协议、Novell网络中的SPX协议和微软的NetBIOS/NetBEUI协议。
网络层（Network Layer）
通过路由选择算法，为报文或分组通过通信子网选择最适当的路径
数据链路层的数据在这一层被转换为数据包，然后通过路径选择、分段组合、顺序、进/出路由等控制，将信息从一个网络设备传送到另一个网络设备。
寻址：数据链路层中使用的物理地址（如MAC地址）仅解决网络内部的寻址问题。在不同子网之间通信时，为了识别和找到网络中的设备，每一子网中的设备都会被分配一个唯一的地址。由于各子网使用的物理技术可能不同，因此这个地址应当是逻辑地址（如IP地址）。
交换：规定不同的信息交换方式。常见的交换技术有：线路交换技术和存储转发技术，后者又包括报文交换技术和分组交换技术。
路由算法：当源节点和目的节点之间存在多条路径时，本层可以根据路由算法，通过网络为数据分组选择最佳路径，并将信息从最合适的路径由发送端传送到接收端。
连接服务：与数据链路层流量控制不同的是，前者控制的是网络相邻节点间的流量，后者控制的是从源节点到目的节点间的流量。其目的在于防止阻塞，并进行差错检测。
数据链路层是解决同一网络内节点之间的通信，而网络层主要解决不同子网间的通信。例如在广域网之间通信时，必然会遇到路由（即两节点间可能有多条路径）选择问题。
数据链路层（Data Link Layer）
物理层提供的比特流的基础上，通过差错控制、流量控制方法，使有差错的物理线路变为无差错的数据链路，即提供可靠的通过物理介质传输数据的方法。
该层通常又被分为介质访问控制（MAC）和逻辑链路控制（LLC）两个子层
MAC子层的主要任务是解决共享型网络中多用户对信道竞争的问题，完成网络介质的访问控制；
LLC子层的主要任务是建立和维护网络连接，执行差错校验、流量控制和链路控制。数据链路层的具体工作是接收来自物理层的位流形式的数据，并封装成帧，传送到上一层；同样，也将来自上层的数据帧，拆装为位流形式的数据转发到物理层；并且，还负责处理接收端发回的确认帧的信息，以便提供可靠的数据传输。
物理层（Physical Layer）
利用传输介质为数据链路层提供物理连接，实现比特流的透明传输。
物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。使其上面的数据链路层不必考虑网络的具体传输介质是什么。
分享一张大而全的七层协议框架图
TCP/IP协议-OSI的一种“实现”
传输控制协议TCP简介
面向连接的、可靠的、基于字节流的传输层通信协议
将应用的数据流分割成报文段并发送个给目标节点的TCP层，
分段的长度受数据链路层MTU(最大传输单元，Maximum Transmission Unit)的限制
TCP单个数据报的最大长度称为最大段尺寸MSS；
在TCP三次握手建立连接的时候，双方会商量传输中MSS的大小；
数据包都有序号以保证消息接收的顺序，对方收到则发送ACK确认，未收到则重传
使用奇偶校验和来校验数据在传输过程中是否有误
TCP报文头
SourcePort：源端口，占用2个字节。源端口和IP地址的作用是标识报文的返回地址。
p.s. IP可以唯一表示一台主机，TCP协议和端口号可以唯一表示主机中的一个进程；所以我们可以根据IP地址+协议+端口号唯一表示网络中的一个进程（即Socket的工作原理）。
DestinationPort：目的端口，占用2个字节；指明接收方计算机上的应用程序的端口。
SequenceNumber（序号seq）：本报文段发送的数据组的第一个字节的序号。e.g.一个报文段的序号为300，此报文段数据部分共有100字节，则下一个报文段的序号为400。所以序号确保了TCP传输的有序性。
AcknowledgmentNumber（确认号ack）：指明下一个期待收到的字节序号，表明该序号之前的所有数据已经正确无误的收到。确认号只有当ACK标志为1时才有效。
offset（数据偏移）：占用4bits。由于首部可能含有可选项内容，因此TCP报头的长度是不确定的，报头不包含任何任选字段则长度为20字节，4位首部长度字段所能表示的最大值为1111，转化为10进制为15，15*32/8 = 60，故报头最大长度为60字节。首部长度也叫数据偏移，是因为首部长度实际上指示了数据区在报文段中的起始偏移值。
Reserved（保留字节）：为将来定义新的用途保留，现在一般置0。
TCP Flags（TCP控制位）
SYN：同步序号，用于建立连接过程，在连接请求中，SYN=1和ACK=0表示该数据段没有使用捎带的确认域，而连接应答捎带一个确认，即SYN=1和ACK=1。
ACK：确认序号标志，为1时表示确认号有效，为0表示报文中不含确认信息，忽略确认号字段。
FIN：finish标志，用于释放连接，为1时表示发送方已经没有数据发送了，即关闭本方数据流。
URG：紧急指针标志，为1时表示紧急指针有效，为0则忽略紧急指针。
PSH：push标志，为1表示是带有push标志的数据，指示接收方在接收到该报文段以后，应尽快将这个报文段交给应用程序，而不是在缓冲区排队。
RST：重置连接标志，用于重置由于主机崩溃或其他原因而出现错误的连接。或者用于拒绝非法的报文段和拒绝连接请求。
CWR：Congestion Window Reduced
ECE：ECN echo
Window（窗口）：滑动窗口大小，用来告知发送端接受端的缓存大小，以此控制发送端发送数据的速率，从而达到流量控制。窗口大小时一个16bit字段，因而窗口大小最大为65535。
Checksum（校验和）：奇偶校验，此校验和是对整个的 TCP 报文段，包括 TCP 头部和 TCP 数据，以 16位进行计算所得。由发送端计算和存储，并由接收端进行验证。
UrgentPointer（紧急指针）：只有当 URG 标志置 1 时紧急指针才有效。紧急指针是一个正的偏移量，和顺序号字段中的值相加表示紧急数据最后一个字节的序号。 TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式。
TCP Options（选项与填充）如果没有选项，则TCP头长度是20字节，TCP选项最大是40个字节。最常见的可选字段是最长报文大小，又称为MSS（Maximum Segment Size），每个连接方通常都在通信的第一个报文段（为建立连接而设置SYN标志为1的那个段）中指明这个选项，它表示本端所能接受的最大报文段的长度。选项长度不一定是32位的整数倍，所以要加填充位，即在这个字段中加入额外的零，以保证TCP头是32的整数倍。
Data（数据部分）TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段。
说说TCP的三次握手
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接
第一次握手：建立连接时，客户端发送SYN包到服务器，并进入SYN_SEND状态，等待服务器确认。这里发送的SYN包，SYN标志位为1，seq序号初始为x
第二次握手：服务器收到SYN包，必须确认客户的SYN，同时自己也发送一个SYN包给客户端，此时服务端进入SYN_RECV状态。这里服务端发送的SYN包中SYN标志位和ACK标志位都是1，seq序号初始为y，ack为x+1（表示客户端下次再发送包seq从x+1开始）
第三次握手：客户端收到服务器的SYN+ACK的包，向服务器发送确认包，此包ACK标志位1，seq序号为x+1，ack为y+1（表示服务端下一次发送数据seq从y+1开始）。此包发送完毕，客户端和服务器端都进入ESTABLISHED状态，完成三次握手，开始数据传送。
为什么需要三次握手才能建立连接
为了初始化SequenceNumber
为了防止服务器端开启一些无用的连接增加服务器开销以及防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
三次握手的隐患-SYN Flood
问题描述
Server收到Client的SYN，回复SYN-ACK的时候未收到ACK确认
Server不断重试直至超时，Linux默认等待63秒才断开连接（Linux默认重试5次，每次等待时间翻倍，第一次重试前等待时间为1秒，第五次重试后等待时间是32秒，然后才断开连接）
恶意攻击者，不断向服务端发送SYN请求后立刻下线，服务器端会等待63秒后才断开连接，进而导致服务端资源耗尽，让正常的连接请求不能处理
针对SYN Flood的防护措施
针对上述问题的解决办法
SYN队列满后，通过tcp_syncookies参数回发SYN Cookie
如果是正常连接，Client会回发SYN Cookie给服务端；如果是恶意攻击，因为Client已经下线，则不会返回。
正常连接返回SYN Cookie后，可以直接建立连接
建立连接后，Client出现故障怎么办
保活机制
向对方发送保活探测报文，如果未收到响应则继续发送
尝试次数达到保活探测数仍未收到响应，则中断连接
TCP四次挥手
挥手是为了终止连接，TCP采用四次挥手来释放连接
第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN-WAIT_1状态；
第二次挥手：Server收到FIN后，发送一个ACK给client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态；Client接收到Server的FIN之后，进入FIN_WAIT_2状态；
第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态；
第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次握手
为什么要有TIME_WAIT状态
防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL，上一次连接中所有的重复包都会消失）
可靠的关闭TCP连接。为的是确认服务器端是否收到客户端发出的ACK确认报文。当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器。MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。
服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；
如果客户端在2MSL内，再次收到了来自服务器端的FIN报文，说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时；
否则客户端在2MSL内没有再次收到来自服务器端的FIN报文，说明服务器端正常接收了ACK确认报文，客户端可以进入CLOSED阶段，完成“四次挥手”。
为什么需要四次握手
因为全双工，发送方和接收方都需要FIN报文和ACK保报文
建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。
服务器出现大量CLOSE_WAIT状态的原因
如果一直保持在CLOSE_WAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。换句话说，就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。
检查代码，特别是释放资源的代码
检查配置，特别是处理请求的线程配置
写了这么多，请允许小猿喘口气~，今天就到这吧，未完待续...
更多精彩可以搜索公众号：隔壁王小猿（happy-gbwxy）关注，公众号留言可以获取JAVA面试宝典哦 (*^▽^*)
