详解计算机网络经典面试题（上）

一、网络分层结构

计算机网络七层模型：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。

• 应用层的任务是通过应用进程之间的交互来完成特定的网络作用，常见的应用层协议有域名系统DNS，HTTP协议等。
• 表示层的主要作用是数据的表示、安全、压缩。可确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。
• 会话层的主要作用是建立通信链接，保持会话过程通信链接的畅通，同步两个节点之间的对话，决定通信是否被中断以及通信中断时决定从何处重新发送。。
• 传输层的主要作用是负责向两台主机进程之间的通信提供数据传输服务。传输层的协议主要有传输控制协议TCP和用户数据协议UDP。
• 网络层的主要作用是选择合适的网间路由和交换结点，确保数据及时送达。常见的协议有IP协议。
• 数据链路层的作用是在物理层提供比特流服务的基础上，建立相邻结点之间的数据链路，通过差错控制提供数据帧（Frame）在信道上无差错的传输，并进行各电路上的动作系列。 常见的协议有SDLC、HDLC、PPP等。
• 物理层的主要作用是实现相邻计算机结点之间比特流的透明传输，并尽量屏蔽掉具体传输介质和物理设备的差异。

我们知道TCP/IP与OSI最大的不同在于：OSI是一个理论上的网络通信模型，而TCP/IP则是实际上的网络通信标准。但是，它们的初衷是一样的，都是为了使得两台计算机能够像两个知心朋友那样能够互相准确理解对方的意思并做出优雅的回应。现在，我们对OSI七层模型的各层进行简要的介绍：

二、三次握手

1、三次握手流程

三次握手（Three-way Handshake）其实就是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。

刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。
进行三次握手：

2、大白话

1、客户端请求连接，发送一个seq初始序列，并发出一个SYN表明是主动打开。
2、服务端接收到客户端的seq，服务端将seq+1后以ack报文的形式响应发出，并发送自己的初始序列seq=y
3、客户端收到服务端的响应，同样将服务端发来的seq+1后，即ack=y+1发出。并且由于是第二次发请求，客户端的seq在原来x的基础上加1后再向服务端发出seq，连接建立。

• 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN（seq）。此时客户端处于 SYN_SENT 状态。

发送第一个SYN的一端将执行主动打开（active open），接收这个SYN并发回下一个SYN的另一端执行被动打开（passive open）。

首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。

• 第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN。同时会把客户端的 ISN + 1 作为ack 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_RCVD 的状态。

在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。

• 第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。

确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。

在socket编程中，客户端执行connect()时，将触发三次握手。

3、为什么需要三次握手，两次不行吗？

大白话：

1、客户端要连接，请求服务端。
2、服务端接收到客户端的连接请求，响应给客户端。
3、客户端收到服务端的响应。
4、此时证明客户端发送、接收正常，服务端发送、接收正常。
5、但是在第二次握手后服务端不知道客户端接收是否正常，所以需要客户端再发送信息跟服务端说：我接收到啦，一切正常！自此才能真正确定上一点。

弄清这个问题，我们需要先弄明白三次握手的目的是什么，能不能只用两次握手来达到同样的目的。

• 第一次握手：客户端发送网络包，服务端收到了。
  这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
• 第二次握手：服务端发包，客户端收到了。
  这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
• 第三次握手：客户端发包，服务端收到了。
  这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

因此，需要三次握手才能确认双方的接收与发送能力是否正常。

试想如果是用两次握手，则会出现下面这种情况：

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

4、什么是半连接队列？

服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称为半连接队列。当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

• 半连接队列，也称 SYN 队列；
• 全连接队列，也称 accepet 队列；

服务端收到客户端发起的 SYN 请求后，内核会把该连接存储到半连接队列，并向客户端响应 SYN+ACK，接着客户端会返回 ACK，服务端收到第三次握手的 ACK 后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到 accept 队列，等待进程调用 accept 函数时把连接取出来。

不管是半连接队列还是全连接队列，都有最大长度限制，超过限制时，内核会直接丢弃，或返回 RST 包。

这里在补充一点关于SYN-ACK 重传次数的问题：
服务器发送完SYN-ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。
注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s，2s，4s，8s…

5、ISN是固定的吗？

ISN(Initial Sequence Number)，当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间而变化，因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器，每4ms加1 。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它做错误的解释。

三次握手的其中一个重要功能是客户端和服务端交换 ISN，以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

6、三次握手过程中可以携带数据吗？

其实第三次握手的时候，是可以携带数据的。但是，第一次、第二次握手不可以携带数据。

为什么这样呢?大家可以想一个问题，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。

也就是说，第一次握手不可以放数据，其中一个简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

7、SYN攻击是什么？

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。

检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。在 Linux/Unix 上可以使用系统自带的 netstat 命令来检测 SYN 攻击。

netstat -n -p TCP | grep SYN_RECV

常见的防御 SYN 攻击的方法有如下几种：

• 缩短超时（SYN Timeout）时间
• 增加最大半连接数
• 过滤网关防护
• SYN cookies技术

三、四次挥手

1、四次挥手流程

建立一个连接需要三次握手，而终止一个连接要经过四次挥手（也有将四次挥手叫做四次握手的）。这由TCP的半关闭（half-close）造成的。所谓的半关闭，其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。

TCP 连接的拆除需要发送四个包，因此称为四次挥手(Four-way handshake)，客户端或服务端均可主动发起挥手动作。

刚开始双方都处于ESTABLISHED 状态，假如是客户端先发起关闭请求。四次挥手的过程如下：

大白话：

客户端和服务端哪端需要释放连接了，哪端就首先发出一个FIN连接释放报文段，并发出一个初始序列seq，响应端接收到seq初始序号后，就将其+1后以ack报文的形式响应发出，并发出自己的初始序列seq，还有一个ACK=1。

• 第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。
  即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。
• 第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值seq +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。
  即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。
• 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
  即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。
• 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值seq +1 作为自己 ack报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ack 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。
  即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。

收到一个FIN只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入TIME_WAIT是正常的，服务端通常执行被动关闭，不会进入TIME_WAIT状态。

在socket编程中，任何一方执行close()操作即可产生挥手操作。

2、为什么A在TIME-WAIT状态必须等待2MSL（最大报文段生存时间）的时间？

• 保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失，B收不到这个确认报文，就会超时重传连接释放报文段，然后A可以在2MSL时间内收到这个重传的连接释放报文段，接着A重传一次确认，重新启动2MSL计时器，最后A和B都进入到CLOSED状态，若A在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到B重传的连接释放报文段，所以不会再发送一次确认报文段，B就无法正常进入到CLOSED状态。
• 防止已失效的连接请求报文段出现在本连接中。A在发送完最后一个ACK报文段后，再经过2MSL，就可以使这个连接所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现旧的连接请求报文段。

3、为什么连接的时候是三次握手，关闭的时候却是四次握手？

• 服务端的LISTEN状态下的SOCKET当收到客户端的SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但若是服务端接收到客户端的连接释放请求报文后，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你未必会马上会关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的连接释放报文我收到了”，也就是可能还需要发送一些数据给对方之后（第二次挥手），再发送FIN报文给对方来表示你同意现在可以关闭连接了（第三次挥手），所以它这里的ACK报文和FIN报文多数情况下都是分开发送的，不能一起发送，故需要四步握手。

四、滑动窗口

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。 TCP会话的双方都各自维护一个发送窗口和一个接收窗口。接收窗口大小取决于应用、系统、硬件的限制。发送窗口则取决于对端通告的接收窗口。接收方发送的确认报文中的window字段可以用来控制发送方窗口大小，从而影、响发送方的发送速率。将接收方的确认报文window字段设置为 0，则发送方不能发送数据。

TCP头包含window字段，16bit位，它代表的是窗口的字节容量，最大为65535。这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。接收窗口的大小是约等于发送窗口的大小。

五、拥塞控制

防止过多的数据注入到网络中。 几种拥塞控制方法：慢开始( slow-start )、拥塞避免( congestion avoidance )、快重传( fast retransmit )和快恢复( fast recovery )。

慢开始

把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。每经过一个传输轮次，拥塞窗口 cwnd 就加倍。 为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量。

当 cwnd < ssthresh 时，使用慢开始算法。

当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。

当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。

拥塞避免

让拥塞窗口cwnd缓慢地增大，每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长。

无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送 方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生 拥塞的路由器有足够时间把队列中积压的分组处理完毕。

快重传

有时个别报文段会在网络中丢失，但实际上网络并未发生拥塞。如果发送方迟迟收不到确认，就会产生超时，就会误认为网络发生了拥塞。这就导致发送方错误地启动慢开始，把拥塞窗口cwnd又设置为1，因而降低了传输效率。

快重传算法可以避免这个问题。快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认，使发送方及早知道有报文段没有到达对方。

发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待重传计时器到期。由于发送方尽早重传未被确认的报文段，因此采用快重传后可以使整个网络吞吐量提高约20%。

快恢复

当发送方连续收到三个重复确认，就会把慢开始门限ssthresh减半，接着把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。

在采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用。 采用这样的拥塞控制方法使得TCP的性能有明显的改进。

六、HTTP

超文本传输协议。

1、主要特点

1. 灵活：HTTP允许传输任意类型的数据。传输的类型由Content-Type加以标记。
2. HTTP 0.9和1.0使用非持续连接：限制每次连接只处理一个请求，服务器处理完客户的请求，并收到客户的应答后，即断开连接。HTTP 1.1支持使用持续连接：一个连接可以处理多个请求，不必为每个请求创建一个新的连接，采用这种方式可以节省传输时间。
3. 无状态：是指服务端对于客户端每次发送的请求都认为它是一个新的请求，上一次会话和下一次会话没有联系；HTTP 协议这种特性有优点也有缺点，优点在于解放了服务器，不会造成不必要连接占用，缺点在于如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。

2、http请求

http请求由请求行、请求头部、空行和请求体四个部分组成。

• 请求行：请求方法，访问的资源URL，使用的HTTP版本；GET和POST是最常见的HTTP方法，除此以外还包括DELETE、HEAD、OPTIONS、PUT、TRACE。
• 请求头包含一些属性，格式为“属性名：属性值”，服务端据此获取客户端的信息，主要有cookie、host、connection、accept-language、accept-encoding、user-agent。
• 请求体：用户的请求数据如用户名，密码等。

3、http响应

HTTP响应也由四个部分组成，分别是：状态行、响应头、空行和响应体。

• 状态行：协议版本，状态码及状态描述。
• 响应头：connection、content-type、content-encoding、content-length、set-cookie、Last-Modified，、Cache-Control、Expires。
• 响应体：服务器返回给客户端的内容。

4、http状态码

5、post和get

GET和POST是HTTP协议中的两种发送请求的方法。GET/POST请求都是TCP连接。

Get方法并没有限制提交的数据长度，HTTP协议规范没有对URL长度进行限制。但是浏览器及服务器可能会对URL长度有限制。

POST方法没有对请求体长度进行限制，但是服务端可以对POST数据大小进行限制，比如tomcat默认限制2M。可以修改conf/server.xml：maxPostSize=0，取消POST的大小限制。

post和get请求的区别：

• GET请求参数通过URL传递，POST的参数放在请求体中。
• GET产生一个TCP数据包；POST产生两个TCP数据包。对于GET方式的请求，浏览器会把请求头和请求体一并发送出去；而对于POST，浏览器先发送请求头，服务器响应100 continue，浏览器再发送请求体。
• GET请求会被浏览器主动缓存，而POST不会，除非手动设置。
• GET请求只能进行url编码，而POST支持多种编码方式。
• GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

6、HTTPS

HTTP协议以明文方式发送内容，不提供任何方式的数据加密，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。而HTTPS协议是由SSL+HTTP协议构建的可进行身份认证（非对称加密）、加密传输（对称加密）的网络协议。SSL作用在应用层和运输层之间，在TCP之上建立起一个安全通道，确保数据传输安全。在 SSL层完成身份认证、加解密操作。

1）数字证书

服务端可以向证书颁发机构CA申请证书，以避免中间人攻击（防止证书被篡改）。证书包含三部分内容：tbsCertificate（to be signed certificate）待签名证书内容、证书签名算法和CA给的签名（使用证书签名算法对tbsCertificate进行哈希运算得到哈希值，CA会用它的私钥对此哈希值进行签名，并放在签名部分）。签名是为了验证身份。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RCv0OFk2-1639056562937)(…/img/net/https-certificate.png)]

服务端把证书传输给浏览器，浏览器从证书里取公钥。证书可以证明该公钥对应该网站。

数字签名的制作过程：

1. CA使用证书签名算法对证书内容（待签名证书内容）进行hash。
2. 对hash后的值用CA自己的私钥加密，得到数字签名。

浏览器验证过程：

1. 拿到证书，得到证书内容、证书签名算法和数字签名。
2. 用CA机构的公钥对数字签名解密（由于是浏览器信任的机构，所以浏览器会保存它的公钥）。
3. 用证书里的签名算法对证书内容进行hash。
4. 比较解密后的数字签名和对证书内容hash后的哈希值，相等则表明证书可信。

2）原理

首先是TCP三次握手，然后客户端（浏览器）发起一个HTTPS连接建立请求，客户端先发一个Client Hello的包，然后服务端响应一个Server Hello，接着再给客户端发送它的证书，然后双方经过密钥交换，最后使用交换的密钥加解密数据。

1. 协商加密算法 。在Client Hello里面客户端会告知服务端自己当前的一些信息，包括客户端要使用的TLS版本，支持的加密套装，要访问的域名，给服务端生成的一个随机数（Nonce）等。需要提前告知服务器想要访问的域名以便服务器发送相应的域名的证书过来。

2. 服务端在Server Hello里面会做一些响应，告诉客户端服务端选中的加密套装。

3. 接着服务给客户端发来了4个证书。第二个证书是第一个证书的签发机构（CA）的证书，它是Amazon，也就是说Amazon会用它的私钥给http://developer.mozilla.org进行签名。依此类推，第三个证书会给第二个证书签名，第四个证书会给第三个证书签名，并且我们可以看到第四个证书是一个根（Root）证书。

4. 客户端使用证书的认证机构CA公开发布的RSA公钥对该证书进行验证。

5. 验证通过之后，浏览器和服务器通过密钥交换算法产生共享的对称密钥。

6. 开始传输数据，使用同一个对称密钥来加解密。

   

3）HTTPS和HTTP的区别

1. http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
2. http和https用的端口不一样，前者是80，后者是443。
3. https协议需要到ca机构申请证书，一般免费证书较少，因而需要一定费用。

7、浏览器中输入URL返回页面过程

总共分为7个步骤：浏览器中输入域名+域名解析+浏览器与目标服务器建立TCP连接+浏览器通过http协议向目标服务器发送请求+服务器给出响应，将指定文件发送给浏览器+TCP释放链接+浏览器显示页面中所有文本

第一步、浏览器中输入域名

www.baidu.com

第二步、域名解析

浏览器会把输入的域名解析成对应的IP，过程如下：

1. 浏览器查找浏览器缓存，如果有域名对应的IP地址则返回，如果没有继续查找。

2. 浏览器查看本机的host文件，如果有域名对应的IP地址则返回，如果没有继续查找。

3. 然后是路由器缓存，路由器一般有自己的缓存，如果有域名对应的IP地址则返回，如果没有继续查找。

4. 接着是对本地DNS服务器进行递归查询，看是否有域名对应的IP。主机向本地域名服务器的查询一般都是采用递归查询。所谓递归查询就是如果主机所询问的本地域名服务器不知道被查询域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其他根域名服务器继续发出查询请求报文，而不是让该主机自己进行下一步查询。（本地域名服务器地址是通过DHPC协议获取地址，DHPC是负责分配IP地址的）

5. 本地域名服务器采用迭代查询，它先向一个根域名服务器查询。本地域名服务器向根域名服务器的查询一般都是采用迭代查询。所谓迭代查询就是当根域名服务器收到本地域名服务器发出的查询请求报文后，要么告诉本地域名服务器下一步应该查询哪一个域名服务器，然后本地服务器自己进行后续的查询。（而不是替代本地服务器进行后续查询）。

6. 根域名服务器告诉本地域名服务器，下一次应查询的顶级域名服务器dns.com的IP地址。

7. 本地域名服务器向顶级域名服务器dns.com进行查询。

8. 顶级域名服务器dns.com告诉本地域名服务器，下一次应查询的权限域名服务器dns.baidu.com的IP地址。

9. 本地域名服务器向权限域名服务器dns.baidu.com进行查询。

10. 权限域名服务器dns.baidu.com告诉本地域名服务器，所查询的主机www.baidu.com的IP地址。

本地域名服务器最后把查询结果告诉主机。

第三步、浏览器与目标服务器建立TCP连接

1. 主机浏览器通过DNS解析得到了目标服务器的IP地址后，与服务器建立TCP连接。

2. TCP的3次握手连接：浏览器所在的客户机向服务器发出连接请求报文；服务器接收报文后，同意建立连接，向客户机发出确认报文；客户机接收到确认报文后，再次向服务器发出报文，确认已接收到确认报文；此处客户机与服务器之间的TCP连接建立完成，开始通信。

第四步、浏览器通过http协议向目标服务器发送请求

请求行，请求头，请求实体内容。浏览器向主机发起一个HTTP-GET方法报文请求。请求中包含访问的URL，也就是http://www.baidu.com/ ，KeepAlive，长连接，还有User-Agent用户浏览器操作系统信息，编码等。值得一提的是Accep-Encoding和Cookies项。Accept-Encoding一般采用gzip，压缩之后传输html文件。Cookies如果是首次访问，会提示服务器建立用户缓存信息，如果不是，可以利用Cookies对应键值，找到相应缓存，缓存里面存放着用户名，密码和一些用户设置项。

第五步、服务器给出响应，将指定文件发送给浏览器

状态行，响应头，响应实体内容，返回状态码200 OK，表示服务器可以响应请求，返回报文，由于在报头中Content-type为“text/html”，浏览器以HTML形式呈现，而不是下载文件。

注意：但是，对于大型网站存在多个主机站点，往往不会直接返回请求页面，而是重定向。返回的状态码就不是200OK，而是301,302以3开头的重定向码，浏览器在获取了重定向响应后，在响应报文中Location项找到重定向地址，浏览器重新第一步访问即可。

补充一点的就是，重定向是为了负载均衡或者导入流量，提高SEO排名。利用一个前端服务器接受请求，然后负载到不同的主机上，可以大大提高站点的业务并发处理能力；重定向也可将多个域名的访问，集中到一个站点；由于baidu.com，www.baidu.com会被搜索引擎认为是两个网站，照成每个的链接数都会减少从而降低排名，永久重定向会将两个地址关联起来，搜索引擎会认为是同一个网站，从而提高排名。

第六步、TCP释放链接

也就是4次挥手：

1. 浏览器所在主机向服务器发出连接释放报文，然后停止发送数据；

2. 服务器接收到释放报文后发出确认报文，然后将服务器上未传送完的数据发送完；

3. 服务器数据传输完毕后，向客户机发送连接释放报文；

4. 客户机接收到报文后，发出确认，然后等待一段时间后，释放TCP连接；

第七步、浏览器显示页面中所有文本。

浏览器接收到返回的数据包，根据浏览器的渲染机制对相应的数据进行渲染。渲染后的数据，进行相应的页面呈现和脚步的交互。

8、长连接

HTTP长连接，指的是复用TCP连接。多个HTTP请求可以复用同一个TCP连接，这就节省了TCP连接建立和断开的消耗。长连接在HTTP1.0时是实验性扩展，HTTP1.1默认设置connection:keep-alive，使用长连接。设置为connection:close可以关闭长连接。客户端和服务器的HTTP首部的Connection都要设置为keep-alive，才能支持长连接。

长连接的过期时间可以通过Keep-Alive: timeout=20或者max=xxx（max表示这个长连接最多接收xxx次请求就断开）设置。

长连接数据传输完成的标志：

• 判断传输数据是否达到了Content-Length指示的大小；

• 分块传输（chunked）没有Content-Length，这时候就要根据chunked编码来判断，chunked编码的数据在最后有一个空chunked块，表明本次传输数据结束。

七、TCP和UDP

TCP：传输控制协议。

UDP：用户数据报协议。

TCP的特点

• TCP是面向连接的运输层协议

• 每一条TCP连接只能有两个端点(一对一)

• TCP提供可靠交付的服务

• TCP提供全双工通信

• 面向字节流

• TCP可靠传输、流量控制和拥塞控制的实现
  TCP的可靠性如何保证：对于收到的请求，给出确认响应。
  流量控制：让发送方的发送速率不要太快，要让接收方来得及接收。利用滑动窗口实现流量控制。
  拥塞控制：防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。
  TCP可靠传输是因为有：数据报校验, 失序数据重排序, 丢弃重复数据,应答机制,超时重发,流量控制等原因

TCP和UDP区别

1. TCP面向连接，UDP是无连接的，即发送数据之前不需要建立连接
2. TCP提供可靠的服务；UDP不保证可靠交付
3. TCP面向字节流，把数据看成一连串无结构的字节流；UDP是面向报文的
4. TCP有拥塞控制；UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
5. 每一条TCP连接只能是点到点的；UDP支持一对一，一对多，多对一和多对多的交互通信
6. TCP首部开销20字节；UDP的首部开销小，只有8个字节

协议

TCP对应的协议：
（1）FTP：定义了文件传输协议，使用21端口。
（2）Telnet：用于远程登陆的端口。
（3）SMTP：定义了简单邮件传送协议，25端口。
（4）POP3：它是和SMTP对应，POP3用于接收邮件，110端口。
（5）HTTP协议：是从万维网服务器传输超文本到本地浏览器的传送协议，使用80端口。

UDP对应的协议：
（1）DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。
（2）SNMP：简单网络管理协议，使用161号端口。
（3）TFTP，Trival File Transfer Protocal，简单文件传输协议，使用端口69。
（4）RIP，路由信息协议。
（5）DHCP，动态主机配置协议。

TCP首部

UDP首部