一文详解计算机网络经典面试题

最新推荐文章于 2024-04-16 06:06:05 发布

Charte

最新推荐文章于 2024-04-16 06:06:05 发布

阅读量3.5k

点赞数 9

分类专栏：计算机网络文章标签：网络网络协议 http 计算机网络面试

本文链接：https://blog.csdn.net/weixin_45296116/article/details/121844561

版权

计算机网络专栏收录该内容

2 篇文章 0 订阅

订阅专栏

一、网络分层结构

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

应用层

通过应用进程之间的交互来完成特定的网络作用，常见的应用层协议有域名系统DNS，HTTP协议等。

表示层

数据的表示、安全、压缩。可确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。

会话层

建立通信链接，保持会话过程通信链接的畅通，同步两个节点之间的对话，决定通信是否被中断以及通信中断时决定从何处重新发送。

传输层

负责向两台主机进程之间的通信提供数据传输服务。传输层的协议主要有传输控制协议TCP和用户数据协议UDP。

网络层

选择合适的网间路由和交换结点，确保数据及时送达。常见的协议有IP协议。

数据链路层

在物理层提供比特流服务的基础上，建立相邻结点之间的数据链路，通过差错控制提供数据帧（Frame）在信道上无差错的传输，并进行各电路上的动作系列。常见的协议有SDLC、HDLC、PPP等。

物理层

实现相邻计算机结点之间比特流的透明传输，并尽量屏蔽掉具体传输介质和物理设备的差异。

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

请添加图片描述

二、三次握手

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 )。

请添加图片描述

1、慢开始

不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。

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

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

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

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

2、拥塞避免

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

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

3、快重传

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

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

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

4、快恢复

当发送方连续收到三个重复确认，就会把慢开始门限ssthresh减半，接着把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。
在这里插入图片描述
在采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用。采用这样的拥塞控制方法使得TCP的性能有明显的改进。

六、HTTP

超文本传输协议。

1、主要特点

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

2、http请求

HTTP请求结构：请求方式 + 请求URI + 协议及其版本
HTTP响应结构：状态码 + 原因短语 + 协议及其版本

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

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

请求报文示例：

POST /xxx HTTP/1.1 请求行
Accept:image/gif.image/jpeg, 请求头部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=dabin 请求体

3、http响应

HTTP请求结构：请求方式 + 请求URI + 协议及其版本
HTTP响应结构：状态码 + 原因短语 + 协议及其版本

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

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

响应报文示例：

HTTP/1.1 200 OK		//消息头
//消息报头
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112
//消息报头
<html>
    <body>响应体</body>
</html>

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会用它的私钥对此哈希值进行签名，并放在签名部分）。签名是为了验证身份。

在这里插入图片描述

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

数字签名的制作过程：

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

浏览器验证过程：

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

2）HTTPS的原理是什么？

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

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

请添加图片描述

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

请添加图片描述

接着服务给客户端发来了4个证书。第二个证书是第一个证书的签发机构（CA）的证书，它是Amazon，也就是说Amazon会用它的私钥给http://developer.mozilla.org进行签名。依此类推，第三个证书会给第二个证书签名，第四个证书会给第三个证书签名，并且我们可以看到第四个证书是一个根（Root）证书。
客户端使用证书的认证机构CA公开发布的RSA公钥对该证书进行验证。
验证通过之后，浏览器和服务器通过密钥交换算法产生共享的对称密钥。
开始传输数据，使用同一个对称密钥来加解密。

3）HTTPS和HTTP的区别是什么？

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

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

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

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

www.baidu.com

第二步、域名解析

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

浏览器查找浏览器缓存，如果有域名对应的IP地址则返回，如果没有继续查找。
浏览器查看本机的host文件，如果有域名对应的IP地址则返回，如果没有继续查找。
然后是路由器缓存，路由器一般有自己的缓存，如果有域名对应的IP地址则返回，如果没有继续查找。
接着是对本地DNS服务器进行递归查询，看是否有域名对应的IP。主机向本地域名服务器的查询一般都是采用递归查询。所谓递归查询就是如果主机所询问的本地域名服务器不知道被查询域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其他根域名服务器继续发出查询请求报文，而不是让该主机自己进行下一步查询。（本地域名服务器地址是通过DHPC协议获取地址，DHPC是负责分配IP地址的）
本地域名服务器采用迭代查询，它先向一个根域名服务器查询。本地域名服务器向根域名服务器的查询一般都是采用迭代查询。所谓迭代查询就是当根域名服务器收到本地域名服务器发出的查询请求报文后，要么告诉本地域名服务器下一步应该查询哪一个域名服务器，然后本地服务器自己进行后续的查询。（而不是替代本地服务器进行后续查询）。
根域名服务器告诉本地域名服务器，下一次应查询的顶级域名服务器dns.com的IP地址。
本地域名服务器向顶级域名服务器dns.com进行查询。
顶级域名服务器dns.com告诉本地域名服务器，下一次应查询的权限域名服务器dns.baidu.com的IP地址。
本地域名服务器向权限域名服务器dns.baidu.com进行查询。
权限域名服务器dns.baidu.com告诉本地域名服务器，所查询的主机www.baidu.com的IP地址。

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

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

主机浏览器通过DNS解析得到了目标服务器的IP地址后，与服务器建立TCP连接。
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次挥手：

浏览器所在主机向服务器发出连接释放报文，然后停止发送数据；
服务器接收到释放报文后发出确认报文，然后将服务器上未传送完的数据发送完；
服务器数据传输完毕后，向客户机发送连接释放报文；
客户机接收到报文后，发出确认，然后等待一段时间后，释放TCP连接；

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

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

8、长连接和短连接是什么？

HTTP长连接，指的是复用TCP连接。多个HTTP请求可以复用同一个TCP连接，这就节省了TCP连接建立和断开的消耗。

长连接在HTTP1.0时是实验性扩展，HTTP1.0默认使用的是短连接。浏览器和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。
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块，表明本次传输数据结束。

9、 HTTP1.1和 HTTP2.0的区别？

HTTP2.0相比HTTP1.1支持的特性：

新的二进制格式：HTTP1.1 基于文本格式传输数据；HTTP2.0采用二进制格式传输数据，解析更高效。
多路复用：在一个连接里，允许同时发送多个请求或响应，并且这些请求或响应能够并行的传输而不被阻塞，避免 HTTP1.1 出现的”队头堵塞”问题。
头部压缩，HTTP1.1的header带有大量信息，而且每次都要重复发送；HTTP2.0 把header从数据中分离，并封装成头帧和数据帧，使用特定算法压缩头帧，有效减少头信息大小。并且HTTP2.0在客户端和服务器端记录了之前发送的键值对，对于相同的数据，不会重复发送。比如请求a发送了所有的头信息字段，请求b则只需要发送差异数据，这样可以减少冗余数据，降低开销。
服务端推送：HTTP2.0允许服务器向客户端推送资源，无需客户端发送请求到服务器获取。

10、DNS 的解析过程？

浏览器搜索自己的DNS缓存
若没有，则搜索操作系统中的DNS缓存和hosts文件
若没有，则操作系统将域名发送至本地域名服务器，本地域名服务器查询自己的DNS缓存，查找成功则返回结果，否则依次向根域名服务器、顶级域名服务器、权限域名服务器发起查询请求，最终返回IP地址给本地域名服务器
本地域名服务器将得到的IP地址返回给操作系统，同时自己也将IP地址缓存起来
操作系统将 IP 地址返回给浏览器，同时自己也将IP地址缓存起来
浏览器得到域名对应的IP地址

11、什么是cookie和session？

由于HTTP协议是无状态的协议，需要用某种机制来识具体的用户身份，用来跟踪用户的整个会话。常用的会话跟踪技术是cookie与session。

cookie就是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。说得更具体一些：当用户使用浏览器访问一个支持cookie的网站的时候，用户会提供包括用户名在内的个人信息并且提交至服务器；接着，服务器在向客户端回传相应的超文本的同时也会发回这些个人信息，当然这些信息并不是存放在HTTP响应体中的，而是存放于HTTP响应头；当客户端浏览器接收到来自服务器的响应之后，浏览器会将这些信息存放在一个统一的位置。自此，客户端再向服务器发送请求的时候，都会把相应的cookie存放在HTTP请求头再次发回至服务器。服务器在接收到来自客户端浏览器的请求之后，就能够通过分析存放于请求头的cookie得到客户端特有的信息，从而动态生成与该客户端相对应的内容。网站的登录界面中“请记住我”这样的选项，就是通过cookie实现的。

关于cookie的失效问题：cookie是服务器生成，存储在客户端浏览器（浏览器进程的内存）或者硬盘中的，它可以分为内存cookie和硬盘cookie。如果是内存cookie，那么一旦关闭当前浏览器窗口cookie就失效了，如果是硬盘cookie，那么它是不会根据浏览器关闭而失效的，它只会根据最初设置它的生命周期的时间而失效，没到时间它就一直有效。那么内存cookie的生存周期是多久呢？一般默认是30分钟，但是这个应该是可以根据服务器端的配置而更改的。在默认的时间内，只要不关闭当前浏览器窗口，cookie就是一直有效的，但是一旦关闭当前浏览器窗口，浏览器进程就会结束，分配的内存也会被清空，cookie自然也就失效了。

cookie工作流程：

servlet创建cookie，保存少量数据，发送给浏览器。
浏览器获得服务器发送的cookie数据，将自动地保存到浏览器端。
下次访问时，浏览器将自动携带cookie数据发送给服务器。

session原理：首先浏览器请求服务器访问web站点时，服务器首先会检查这个客户端请求是否已经包含了一个session标识、称为SESSIONID，如果已经包含了一个sessionid则说明以前已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使用，如果客户端请求不包含session id，则服务器为此客户端创建一个session，并且生成一个与此session相关联的独一无二的sessionid存放到cookie中，这个sessionid将在本次响应中返回到客户端保存，这样在交互的过程中，浏览器端每次请求时，都会带着这个sessionid，服务器根据这个sessionid就可以找得到对应的session。以此来达到共享数据的目的。 这里需要注意的是，session不会随着浏览器的关闭而死亡，而是等待超时时间。

Cookie和Session的区别？

作用范围不同，Cookie 保存在客户端，Session 保存在服务器端。
有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
隐私策略不同，Cookie 存储在客户端，容易被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
存储大小不同，单个 Cookie 保存的数据不能超过 4K；对于 Session 来说存储没有上限，但出于对服务器的性能考虑，Session 内不要存放过多的数据，并且需要设置 Session 删除机制。

12、什么是Application？

Application（Java Web中的ServletContext）：与一个Web应用程序相对应，为应用程序提供了一个全局的状态，所有客户都可以使用该状态。

13、URI和URL的区别是什么?

URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
URL(Uniform Resource Location) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。

URI的作用像身份证号一样，URL的作用更像家庭住址一样。URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

七、TCP和UDP

TCP：传输控制协议。

UDP：用户数据报协议。

1、TCP的特点

TCP是面向连接的运输层协议
每一条TCP连接只能有两个端点(一对一)
TCP提供可靠交付的服务
TCP提供全双工通信
面向字节流
TCP可靠传输、流量控制和拥塞控制的实现
TCP的可靠性如何保证：对于收到的请求，给出确认响应。
流量控制：让发送方的发送速率不要太快，要让接收方来得及接收。利用滑动窗口实现流量控制。
拥塞控制：防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。
TCP可靠传输是因为有：数据报校验, 失序数据重排序, 丢弃重复数据,应答机制,超时重发,流量控制等原因

2、TCP和UDP区别

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

3、协议

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，动态主机配置协议。

请添加图片描述

4、TCP首部

5、UDP首部

八、SQL注入

SQL注入就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，通过该字符串和底层代码中原有的SQL语句进行拼接，使其没有语法错误的同时又能达到欺骗服务器执行恶意的SQL命令的效果。

1). SQL注入攻击的总体思路

(1). 寻找到SQL注入的位置
(2). 判断服务器类型和后台数据库类型
(3). 针对不通的服务器和数据库特点进行SQL注入攻击

2). SQL注入攻击实例

比如，在一个登录界面，要求输入用户名和密码，可以这样输入实现免帐号登录：

用户名： ‘or 1 = 1 --
密 码：（随便写）

用户一旦点击登录，如若没有做特殊处理，那么这个非法用户就很得意的登陆进去了。这是为什么呢?下面我们分析一下：从理论上说，后台认证程序中会有如下的SQL语句：

String sql = “select * from user_table where username=’“+userName+”’ and password=’“+password+”‘”;

因此，当输入了上面的用户名和密码，上面的SQL语句变成：

SELECT * FROM user_table WHERE username=’’or 1 = 1 – and password=’’

分析上述SQL语句我们知道， username=’’ or 1=1 这个语句一定会成功；然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用。这样，上述语句永远都能正确执行，用户轻易骗过系统，获取合法身份。

3). 应对方法

(1). 参数绑定

使用预编译手段，绑定参数是最好的防SQL注入的方法。目前许多的ORM框架及JDBC等都实现了SQL预编译和参数绑定功能，攻击者的恶意SQL会被当做SQL的参数而不是SQL命令被执行。在mybatis的mapper文件中，对于传递的参数我们一般是使用#和 $ 来获取参数值。当使用#时，变量是占位符，就是一般我们使用javajdbc的PrepareStatement时的占位符，所有可以防止sql注入；当使用$时，变量就是直接追加在sql中，一般会有sql注入问题。

(2). 使用正则表达式过滤传入的参数

九、 XSS 攻击

XSS是一种经常出现在web应用中的计算机安全漏洞，与SQL注入一起成为web中最主流的攻击方式。XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些脚本代码嵌入到web页面中去，使别的用户访问都会执行相应的嵌入代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

1). XSS攻击的危害

盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号、控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力、盗窃企业重要的具有商业价值的资料、非法转账、强制发送电子邮件、网站挂马、控制受害者机器向其它网站发起攻击等

2). 原因解析

主要原因：过于信任客户端提交的数据！

解决办法：不信任任何客户端提交的数据，只要是客户端提交的数据就应该先进行相应的过滤处理然后方可进行下一步的操作。

进一步分析细节：客户端提交的数据本来就是应用所需要的，但是恶意攻击者利用网站对客户端提交数据的信任，在数据中插入一些符号以及javascript代码，那么这些数据将会成为应用代码中的一部分了，那么攻击者就可以肆无忌惮地展开攻击啦，因此我们绝不可以信任任何客户端提交的数据！

3). XSS 攻击分类

(1). 反射性XSS攻击 (非持久性XSS攻击)

漏洞产生的原因是攻击者注入的数据反映在响应中。一个典型的非持久性XSS攻击包含一个带XSS攻击向量的链接(即每次攻击需要用户的点击)，例如，正常发送消息：

http://www.test.com/message.php?send=Hello,World！

接收者将会接收信息并显示Hello,World；但是，非正常发送消息：

http://www.test.com/message.php?send=<script>alert(‘foolish!’)</script>！

接收者接收消息显示的时候将会弹出警告窗口！

(2). 持久性XSS攻击 (留言板场景)

XSS攻击向量(一般指XSS攻击代码)存储在网站数据库，当一个页面被用户打开的时候执行。也就是说，每当用户使用浏览器打开指定页面时，脚本便执行。与非持久性XSS攻击相比，持久性XSS攻击危害性更大。从名字就可以了解到，持久性XSS攻击就是将攻击代码存入数据库中，然后客户端打开时就执行这些攻击代码。

例如，留言板表单中的表单域：

<input type=“text” name=“content” value=“这里是用户填写的数据”>

正常操作流程是：用户是提交相应留言信息 —— 将数据存储到数据库 —— 其他用户访问留言板，应用去数据并显示；而非正常操作流程是攻击者在value填写:

<script>alert(‘foolish!’)；</script> 
<!--或者html其他标签（破坏样式。。。）、一段攻击型代码-->

并将数据提交、存储到数据库中；当其他用户取出数据显示的时候，将会执行这些攻击性代码。

4). 修复漏洞方针

漏洞产生的根本原因是太相信用户提交的数据，对用户所提交的数据过滤不足所导致的，因此解决方案也应该从这个方面入手，具体方案包括：

将重要的cookie标记为http only, 这样的话Javascript 中的document.cookie语句就不能获取到cookie了。（如果在cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击）

表单数据规定值的类型，例如：年龄应为只能为int、name只能为字母数字组合。

对数据进行Html Encode 处理过滤或移除特殊的Html标签，例如:

<script>, <iframe> , < for <, > for>, &quot for

过滤JavaScript 事件的标签，例如 “οnclick=”, “onfocus” 等等。

需要注意的是，在有些应用中是允许html标签出现的，甚至是javascript代码出现。因此，我们在过滤数据的时候需要仔细分析哪些数据是有特殊要求（例如输出需要html代码、javascript代码拼接、或者此表单直接允许使用等等），然后区别处理！

十、TCP/IP

1、什么是TCP/IP？

具体来说，IP 或 ICMP、TCP 或 UDP、TELNET 或 FTP、以及 HTTP 等都属于 TCP/IP 协议。他们与 TCP 或 IP 的关系紧密，是互联网必不可少的组成部分。TCP/IP 一词泛指这些协议，因此，有时也称 TCP/IP 为网际协议群。
在这里插入图片描述

2、什么是数据包？

包、帧、数据包、段、消息

以上五个术语都用来表述数据的单位，大致区分如下：

包可以说是全能性术语；
帧用于表示数据链路层中包的单位；
数据包是 IP 和 UDP 等网络层以上的分层中包的单位；
段则表示 TCP 数据流中的信息；
消息是指应用协议中数据的单位。

每个分层中，都会对所发送的数据附加一个首部，在这个首部中包含了该层必要的信息，如发送的目标地址以及协议相关信息。通常，为协议提供的信息为包首部，所要发送的内容为数据。在下一层的角度看，从上一层收到的包全部都被认为是本层的数据。
数据包首部

网络中传输的数据包由两部分组成：一部分是协议所要用到的首部，另一部分是上一层传过来的数据。首部的结构由协议的具体规范详细定义。在数据包的首部，明确标明了协议应该如何读取数据。反过来说，看到首部，也就能够了解该协议必要的信息以及所要处理的数据。包首部就像协议的脸。
在这里插入图片描述

互联网进行通信时，需要相应的网络协议，TCP/IP 原本就是为使用互联网而开发制定的协议族。因此，互联网的协议就是 TCP/IP，TCP/IP 就是互联网的协议。

IP（IPv4、IPv6）相当于 OSI 参考模型中的第3层——网络层。网络层的主要作用是“实现终端节点之间的通信”。这种终端节点之间的通信也叫“点对点通信”。
网络层的下一层——数据链路层的主要作用是在互连同一种数据链路的节点之间进行包传递。而一旦跨越多种数据链路，就需要借助网络层。网络层可以跨越不同的数据链路，即使是在不同的数据链路上也能实现两端节点之间的数据包传输。
IP 大致分为三大作用模块，它们是 IP 寻址、路由（最终节点为止的转发）以及 IP 分包与组包。
在计算机通信中，为了识别通信对端，必须要有一个类似于地址的识别码进行标识。在数据链路中的 MAC 地址正是用来标识同一个链路中不同计算机的一种识别码。
作为网络层的 IP ,也有这种地址信息，一般叫做 IP 地址。IP 地址用于在“连接到网络中的所有主机中识别出进行通信的目标地址”。因此，在 TCP/IP 通信中所有主机或路由器必须设定自己的 IP 地址。
不论一台主机与哪种数据链路连接，其 IP 地址的形式都保持不变。
IP 地址（IPv4 地址）由32位正整数来表示。IP 地址在计算机内部以二进制方式被处理。然而，由于我们并不习惯于采用二进制方式，我们将32位的 IP 地址以每8位为一组，分成4组，每组以 “.” 隔开，再将每组数转换成十进制数。如下：

3、TCP/IP协议的工作流程（数据处理流程）是什么？

在源主机上，应用层将一串应用数据流传送给传输层。
首先应用程序会进行编码处理，这些编码相当于 OSI 的表示层功能；编码转化后，邮件不一定马上被发送出去，这种何时建立通信连接何时发送数据的管理功能，相当于 OSI 的会话层功能。
传输层将应用层的数据流截成分组，并加上TCP报头形成TCP段，送交网络层。
TCP 提供将应用层发来的数据顺利发送至对端的可靠传输。为了实现这一功能，需要在应用层数据的前端附加一个 TCP 首部。
在网络层，经过一些处理（如下）后，将IP数据包送交链路层。
IP 将 TCP 传过来的 TCP 首部和 TCP 数据合起来当做自己的数据，并在 TCP 首部的前端加上自己的 IP 首部。IP 包生成后，参考路由控制表决定接受此 IP 包的路由或主机。
在链路层，网络接口（以太网驱动）处理
从 IP 传过来的 IP 包对于以太网来说就是数据。给这些数据附加上以太网首部并进行发送处理，（链路层在其MAC帧的数据部分装上IP数据包，再加上源、目的主机的MAC地址和帧头），并根据其目的MAC地址，将MAC帧发往目的主机或IP路由器（生成的以太网数据包将通过物理层传输给接收端。）。
在目的主机，链路层将MAC帧的帧头去掉，并将IP数据包送交网络层。
主机收到以太网包后，首先从以太网包首部找到 MAC 地址判断是否为发送给自己的包，若不是则丢弃数据。如果是发送给自己的包，则从以太网包首部中的类型确定数据类型，再传给相应的模块，如 IP、ARP 等。这里的例子则是 IP （网络层）。
网络层检查IP报头，将数据发送给传输层。
如果报头中校验和与计算结果不一致，则丢弃该IP数据包；若校验和与计算结果一致，则去掉IP报头，根据首部的协议类型将数据发送给对应的模块，如 TCP、UDP。这里的例子则是 TCP（传输层）。另外，对于有路由器的情况，接收端地址往往不是自己的地址，此时，需要借助路由控制表，在调查应该送往的主机或路由器之后再进行转发数据。
传输层判断数据是否被破坏，以此决定与源主机或应用层通信。
首先会计算一下校验和，判断数据是否被破坏。然后检查是否在按照序号接收数据。最后检查端口号，确定具体的应用程序。数据被完整地接收以后，会传给由端口号识别的应用程序。若正确，则向源主机发确认信息，并去掉TCP报头，将排好顺序的分组组成应用数据流送给应用程序。；若不正确或丢包，则向源主机要求重发信息。
在应用层，接收端应用程序会直接接收发送端发送的数据。
通过解析数据，展示相应的内容目的主机接收到的来自源主机的字节流，就像是直接接收来自源主机的字节流一样。

4、IP地址的定义及分类是什么？

定义

Internet Protocol，网际互连协议的英文缩写是IP，是TCP/IP体系中的网络层协议。设计IP的目的是提高网络的可扩展性：一是解决互联网问题，实现大规模、异构网络的互联互通；二是分割顶层网络应用和底层网络技术之间的耦合关系，以利于两者的独立发展。根据端到端的设计原则，IP只为主机提供一种无连接、不可靠的、尽力而为的数据包传输服务。

分类

IP地址为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。IP地址编址方案将IP地址空间划分为A、B、C、D、E五类，其中A、B、C是基本类，D、E类作为多播和保留使用，为特殊地址。

每个IP地址包括两个标识码（ID），即网络ID和主机ID。同一个物理网络上的所有主机都使用同一个网络ID，网络上的一个主机（包括网络上工作站，服务器和路由器等）有一个主机ID与其对应。A~E类地址的特点如下：

A类地址：以0开头，第一个字节范围：0~127；
B类地址：以10开头，第一个字节范围：128~191；
C类地址：以110开头，第一个字节范围：192~223；
D类地址：以1110开头，第一个字节范围为224~239；
E类地址：以1111开头，保留地址

IP地址与物理地址

物理地址是数据链路层和物理层使用的地址，IP地址是网络层和以上各层使用的地址，是一种逻辑地址，其中ARP协议用于IP地址与物理地址的对应。

5、网络层的ARP协议工作原理是什么？

网络层的ARP协议完成了IP地址与物理地址的映射。首先，每台主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址的对应关系。当源主机需要将一个数据包要发送到目的主机时，会首先检查自己ARP列表中是否存在该IP地址对应的MAC地址：如果有，就直接将数据包发送到这个MAC地址；如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。此ARP请求数据包里包括源主机的IP地址、硬件地址、以及目的主机的IP地址。网络中所有的主机收到这个ARP请求后，会检查数据包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已经存在该IP的信息，则将其覆盖，然后给源主机发送一个ARP响应数据包，告诉对方自己是它需要查找的MAC地址；源主机收到这个ARP响应数据包后，将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息开始数据的传输。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。