一、网络模型

(1) OSI（开放系统互联）参考模型

物理层： 在物理媒体上为数据端设备透明的传输原始比特流。传输单位是比特。

数据链路层： 成帧、差错控制、流量控制和传输管理。传输单位是帧。

网络层： 对分组进行路由选择，并进行流量控制、拥塞控制、差错控制和网际互连。传输单位是数据 报，即分组。

运输层： 为端到端的连接提供可靠的传输服务，为端到端连接提供流量控制、差错控制、服务质量、 数据传输管理。传输单位是报文段（TCP）或用户数据报（UDP）。

会话层： 建立同步

表示层： 数据压缩、加密、解密、数据的格式转化

应用层： 为特定类型的网络应用提供访问OSI环境的手段

(2) TCP/IP模型

网络接口层： 对应OSI中物理层和数据链路层

网际层：

传输层：

应用层： 对应OSI中会话层、表示层和应用层

二、网络设备

中继器： 又称转发器，原理是信号再生，扩大网络传输距离，不存储，不检错，工作在物理层

集线器： 一个多端口的中继器，工作在物理层

网桥： 处理对象是帧，存储并转发帧并进行路径选择，可以隔离冲突域，但不能隔离广播域，工作在数据链路层的MAC子层

交换机： 多端口的网桥，工作在数据链路层

路由器： 完成路由选择和分组转发，可以隔离冲突与和广播域，实现了网络模型的物理层、数据链路层和网络层，工作在网络层

网关： 网络中网络之间的关卡，保证网络的互连、翻译和转换 应用层

三、网络协议

(1) 数据链路层网络协议

CSMA/CD（载波监听多路访问/碰撞检测）协议： 先听后发，边听边发，冲突停发，随机重发

PPP（点对点）协议： 面向字节，是一种广域网数据链路层控制协议

HDLC（高级数据链路控制）协议： 面向比特，是一种广域网数据链路层控制协议

(2) 网络层

IP协议

ARP（地址解析）协议： 解决同一局域网上从IP地址到硬件地址的映射问题。

ICMP（网际控制报文）协议： 允许主机或路由器报告差错和异常情况，分为ICMP差错报文和ICMP询问报文，可当做IP数据报的数据部分发送

(3) 传输层

OSPF（开放最短路径优先）协议： 直接使用IP数据报传送

UDP协议： 在IP数据报基础上增加了复用、分用和差错检测，无需建立连接，面向报文的，不可靠传输，传输的可靠性需要用户在应用层保证，性能较好，首部8字节。多用在视频、影音等即时通讯中

TCP协议： 面向连接，提供可靠的数据传输，保证数据不丢失、不重复且有序，首部前20字节是固定的。

(4) 应用层

DHCP（动态主机配置）协议： 给主机动态的分配IP地址，基于UPD

RIP（路由信息）协议： 分布式的基于距离向量的路由选择协议，基UPD

BGP（边界网关）协议： 采用的是路径向量路由选择协议，基于TCP

DNS（域名系统）协议： 把域名解析为IP地址，基于UDP协议，工作在53号端口

FTP（文件传输）协议： 允许客户指明文件的类型与格式，并允许文件具有存取权限，基于TCP，工作在21号端口

SMTP（简单邮件传输）协议： 基于TCP，工作在25号端口

POP3（邮局）协议： 邮件读取协议，基于TCP

HTTP（超文本传输）协议： 浏览器怎么向万维网请求文档，以及服务器怎么把文档传给浏览器。基于TCP协议，工作在80号端口

四、TCP三次握手四次挥手：

序列号seq： 占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生；给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号。

确认号ack： 占4个字节，期待收到对方下一个报文段的第一个数据字节的序号；序列号表示报文段携带数据的第一个字节的编号；而确认号指的是期望接收到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号。

确认ACK： 占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效

同步SYN： 连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。

终止FIN： 用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接

PS：ACK、SYN和FIN这些大写的单词表示标志位，其值要么是1，要么是0；ack、seq小写的单词表示序号。

字段	含义
URG	紧急指针是否有效。为1，表示某一位需要被优先处理
ACK	确认号是否有效，一般置为1。
PSH	提示接收端应用程序立即从TCP缓冲区把数据读走。
RST	对方要求重新建立连接，复位。
SYN	请求建立连接，并在其序列号的字段进行序列号的初始值设定。建立连接，设置为1
FIN    	希望断开连接。

三次握手过程理解

1. 第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。

2. 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；

3. 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

四次挥手过程理解

1. 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

2. 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

3. 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

4. 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

5. 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

6. 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

常见面试题

【问题1】为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

【问题3】为什么不能用两次握手进行连接？

答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

【问题4】如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

五.请你说说 TCP 和 UDP 的区别

1.介绍TCP：

TCP 是运输层协议，用于提供面向连接的可靠传输，

特点：

面向连接（需要三次握手四次挥手）

单播（只能端对端的连接）

可靠交付（有大量的机制保护TCP连接数据的可靠性）

全双工通讯（允许双方同时发送信息，也是四次挥手的原由）、

面向字节流（不保留数据报边界的情况下以字节流的方式进行传输，这也是长连接的由来。）

头部开销大（最少20字节）。包括源端口号、目的端口号、序列号、确认号、窗口大小、校验和。

在要求数据准确、对速度没有硬性要求的场景有很好的表现，比如在FTP（文件传输）、HTTP/HTTPS（超文本传输），TCP很适合这种要求。

优点：

可靠、稳定，有确认、窗口、重传、拥塞控制机制，在数据传完之后，还会断开连接用来节约系统资源。

缺点：

慢，效率低，占用系统资源高，在传递数据之前要先建立连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞机制等都会消耗大量的时间，而且要在每台设备上维护所有的传输连接。

2.介绍UDP：

UDP是运输层协议，用于提供面向无连接的不可靠传输，

面向无连接（不需要三次握手和四次挥手）、尽最大努力交付、面向报文（每次收发都是一整个报文 段）、没有拥塞控制不可靠（只管发不管过程和结果）、支持一对一、一对多、多对一和多对多的通 信方式、首部开销很小（8字节）。 语音通话、视频会议、游戏、广播等要求源主机要以恒定的速率发送数据报，允许网络不好的时候丢 失一些数据，但不允许太大的延迟，UDP很适合这种要求。

优点： 快，没有TCP各种机制，少了很多首部信息和重复确认的过程，节省了大量的网络资源。

缺点： 不可靠不稳定，只管数据的发送不管过程和结果，网络不好的时候很容易造成数据丢失。又因为网络不好的时候不会影响到主机数据报的发送速率，这对很多实时的应用程序很重要，因为像

3、UDP和tcp的区别

1. TCP面向连接， 通过三次握手建立连接，四次挥手接除连接；UDP是无连接的，即发送数据之前不需要建立连接，这种方式为UDP带来了高效的传输效率，但也导致无法确保数据的发送成功。

2. 通过TCP连接传送的数据，TCP通过超时重传、 数据校验等方式来确保数据无差错，不丢失，不重复，且按序到达；而UDP由于无需连接的原因，将会以最大速度进行传输，但不保证可靠交付，也就是会出现丢失、重复等等问题。

3. TCP面向字节流 ，实际上是TCP把数据看成一连串无结构的字节流，由于连接的问题，当网络出现波动时，连接可能出现响应问题；UDP是面向报文的，UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低。

4. 每一条TCP连接只能是点到点的；而UDP不建立连接，所以可以支持一对一，一对多，多对一和多对多的交互通信，也就是可以同时接受多个人的包。

5. TCP需要建立连接，

6. 首部开销20字节相比8个字节的UDP显得比较大。

7. TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

8. UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。

4.TCP和UDP的相同：

都是为应用层程序服务，都具有复用（不同的应用层协议可以共用 UDP 协议和 TCP 协议）和分用（将数据报解析之后分发给不同的应用层程序）的功能。

六、TCP 如何实现可靠传输

可靠传输就是通过TCP连接传送的数据是没有差错、不会丢失、不重复并且按序到达的。TCP是通过序 列号、检验和、确认应答信号、重发机制、连接管理、窗口控制、流量控制、拥塞控制一起保证TCP传 输的可靠性的。

加分回答：

可靠传输的具体实现是：

• 应用层的数据会被分割成TCP认为最适合发送的数据块。

• 序列号：TCP给发送的每一个包都进行编号，接收方对数据包进行排序，把有序数据传送给应用层， TCP的接收端会丢弃重复的数据。

• 检验和：TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。

• 确认应答：如果收到的数据报报文段的检验和没有差错，就确认收到，如果有差错，TCP就丢弃这个报文段和不确认收到此报文段。

• 流量控制：TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。

• 拥塞控制：当网络拥塞时，减少数据的发送。

• 停止等待协议：它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。

• 超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

七、TCP 的流量控制 && 滑动窗口

流量控制

如果发送方把数据发送得过快，接收方可能就来不及接受到所有的数据，中间可能会丢失数据报。流量控制就是让发送方的发送速率不要过快，让接收方来得及接收所有的数据。

利用滑动窗口这个机制可以很方便的实现在TCP连接上控制对方发送数据报的速率。例如：客户端和服务器端建立TCP连接的时候，客户端告诉服务器“我的接收窗口，rwnd= 400”，这时候服务器端的 发送窗口发送的数据报总大小不能超过客户端给出的接收窗口的数值，这里要注意的是，这个数值的单位是字节，而不是报文段。当客户端可以继续接收新的数据报时，发送ACK=1 ack=（上一个报文段序号）+1 rwnd = 100，再接收100个字节的数据报。

滑动窗口

滑动窗口是流量控制的一种机制，包括发送方的发送窗口和接收方的接收窗口。在发送窗口范围内的数据可以无需等待确认，继续发送窗口内数据，直到把发送窗口内的数据发送完毕。那么发送窗口中就存在着已发送但未收到确认的数据和允许发送但未发送的数据，每当收到正确的确认数据时，滑动窗口就会向前移动。

接收窗口在按序收到最前面的数据后会向前移动。

发送窗口的大小=min(拥塞窗口大小，接收窗口的大小)在流量控制中那些已经被客户端发送但是还未被确认的分组的许可序号范围可以被看成是一个在序号范围内长度为N的窗口，随着TCP协议的运行、数据的运输，这个窗口在序号空间向前滑动，因此这个窗口被称为滑动窗口。 加分回答 定义一个基序号（base）为最早未确认分组的序号，将下一个序号（nextseqnum）定义为最小的未使用序号（即下一个待分发的分组），那么就可以将整个报文段分为四组，即：

• 已被确认的分组 -
• 已发送但未被确认的分组
• 下一个可以分发的分组
• 超出窗口长度之后的待使用的分

八、TCP超时重传

TCP可靠性中最重要的一个机制是处理数据超时和重传。

TCP协议要求在发送端每发送一个报文段，就启动一个定时器并等待确认信息。接收端成功接收新数据 后返回确认信息。若在定时器超时前数据未能被确认，TCP就认为报文段中的数据已丢失或损坏，需 要对报文段中的数据重新组织和重传。

加分回答

影响超时重传机制协议效率的一个关键参数是重传超时时间（RTO）。

如果RTO设置过大将会使发送端经过较长时间的等待才能发现报文段丢失，降低了连接数据传输的吞吐量。另一方面，若RTO过小，发送端尽管可以很快地检测出报文段的丢失，但也可能将一些延迟大的报文段误认为是丢失，造成不必要的重传，浪费了网络资源。

TCP协议使用自适应算法以适应互联网分组传输时延的变化。这种算法的基本要点是TCP监视每个连接的性能（即传输时延），由此每一个TCP连接推算出合适的RTO值，当连接时延性能变化时，TCP也能够相应地自动修改RTO的设定，以适应这种网络的变化。

TCP协议采用自适应算法记录数据包的往返时延，并根据往返时延设定RTO的取值。

一般来说，RTO的取值会略大于往返时间RTT以保证数据包的正常传输。

建议RTO的计算方式为： RTO = RTTs + 4xRTTd 其中RTTs为加权平均往返时间，RTTd是偏差的加权平均值。

第一次测量往返时间时，SRTT值就取所测量到的RTT样本值，但以后每测量到一个新的往返时间样本，就按下面的式子重新计算一次加权往返时间RTTs： RTTs = α ×（旧RTTs）+（1-α）×（新RTT）

九、说说端到端，点到点的区别

端到端通信： 是针对传输层来说的，也就是从发送端到接收端，包括TCP和UDP。

点到点通信： 是针对数据链路层或网络层来说的，只负责直接相连的两个节点之间的通信，基于MAC地 址或IP地址。

端到端的优点：

链路建立之后，发送端知道接收端一定能收到，而且经过中间交换设备时不需要进行存储转发，因此传输延迟小。

端到端传输的缺点：

直到接收端收到数据为止，发送端的设备一直要参与传输。如果整个传输的延迟很长，那么对发送端的设备造成很大的浪费。

十、SYN攻击底层原理是什么？（要答到内核的半连接队列）

SYN攻击属于DOS攻击的一种，它利用TCP协议缺陷，通过发送大量的半连接请求，耗费CPU和内存资源。SYN攻击除了能影响主机外，还可以危害路由器、防火墙等网络系统，事实上SYN攻击并不管目标是什么系统，只要这些系统打开TCP服务就可以实施。服务器接收到连接请求（syn=j），将此信息加入半连接队列，并发送请求包给客户（syn=k,ack=j+1），此时进SYN_RECV状态。当服务器未收到客户端的确认包时，重发请求包，一直到超时，才将此条目从未连接队列删除。

配合IP欺骗，SYN攻击能达到很好的效果，通常，客户端在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的SYN包将长时间占用半连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。

半连接请求 和半连接队列 ：

半连接队列：

在三次握手协议中，服务器维护一个未连接队列，该队列为每个客户端的SYN包（syn=j）开设一个条目，该条目表明服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的连接在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。

半连接请求：

服务器接收到连接请求（syn=j），将此信息加入半连接队列，并发送请求包给客户（syn=k,ack=j+1），此时进入SYN_RECV状态。当服务器未收到客户端的确认包时，重发请求包，一直到超时，才将此条目从未连接队列删除。

如何防止syn flood攻击： SYN 代理防火墙：服务器防火墙会对收到的每一个 SYN 报文进行代理和回应，并保持半连接。等发送方将 ACK 包返回后，再重新构造 SYN 包发到服务器，建立真正的 TCP 连接

十一、拥塞问题以及如何解决

引言

计算机网络中的带宽、交换结点中的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏。这种情况就叫做拥塞。

拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制是一个全局性的过程，和流量控制不同，流量控制指点对点通信量的控制。

慢开始与拥塞避免

发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口可能小于拥塞窗口。

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

这里用报文段的个数的拥塞窗口大小举例说明慢开始算法，实时拥塞窗口大小是以字节为单位的。如下图：

当然收到单个确认但此确认多个数据报的时候就加相应的数值。所以一次传输轮次之后拥塞窗口就加倍。这就是乘法增长，和后面的拥塞避免算法的加法增长比较。

为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下：

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

当cwnd>ssthresh时，改用拥塞避免算法。

当cwnd=ssthresh时，慢开始与拥塞避免算法任意。

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

无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理），就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法。如下图：

  再次提醒这里只是为了讨论方便而将拥塞窗口大小的单位改为数据报的个数，实际上应当是字节。

快重传和快恢复

快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。如下图：

快重传配合使用的还有快恢复算法，有以下两个要点:

①当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢开始算法。

②考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。如下图：

十二、基于udp设计可靠/udp优化：

在应用层实现可靠传输关键点有两个，从应用层角度考虑分别是：

1. 提供超时重传机制，能避免数据报丢失的问题。

2. 提供确认序列号，保证数据拼接时候的正确排序。

请求端： 首先在UDP数据报定义一个首部，首部包含确认序列号和时间戳，时间戳是用来计算RTT(数据报传输的往返时间)，计算出合适的RTO(重传的超时时间)。然后以等-停的方式发送数据报，即收到对端的确认之后才发送下一个的数据报。当时间超时，本端重传数据报，同时RTO扩大为原来的两倍，重新开始计时。

响应端： 接受到一个数据报之后取下该数据报首部的时间戳和确认序列号，并添加本端的确认数据报

首部之后发送给对端。根据此序列号对已收到的数据报进行排序并丢弃重复的数据报

• 降低了连接建立时延
• 改进了握手控制
• 多路复用
• 避免线头阻塞
• 前向纠错
• 连接迁移
• 默认使用 TLS 1.3 作为全链路安全

十三、url渲染过程

从输入URL到渲染出整个页面的过程包括三个部分：

DNS解析URL > 浏览器发送请求与服务器交互 > 浏览器对接收到的html页面渲染

浏览器与服务器交互过程

输入地址，浏览器查找向DNS服务器发送请求，查找该域名的 IP 地址。

浏览器向该 IP 地址的web 服务器发送一个 HTTP 请求，在发送请求之前浏览器和服务器建立TCP的 三次握手，判断是否是HTTP缓存，如果是强制缓存且在有效期内，不再向服务器发请求，如果是 HTTP协商缓存向后端发送请求且和后端服务器对比，在有效期内，服务器返回304，直接从浏览器获 取数据，如果不在有效期内服务器返回200，返回新数据。如果请求发送出去服务器返回重定向，则浏览器再按照重定向的地址重新发送请求。

如果请求的参数有问题，服务器端返回404，如果服务器端挂了返回500。

如果有数据一切正常，当浏览器拿到服务器的数据之后，开始渲染页面同时获取HTML页面中图片、音频、视频、CSS、JS等。

1.DNS解析URL的过程:

DNS解析的过程就是寻找哪个服务器上有请求的资源。因为ip地址不容易记忆，一般会使用URL域名（如www.baidu.com） 作为网址。DNS解析就是将域名翻译成IP地址的过程。 具体过程：

1. 浏览器缓存：浏览器会按照一定的频率 缓存DNS记录

2. 操作系统：如果浏览器缓存中找不到，就会去操作系统中找（host文件）

3. 路由缓存：路由器也有DNS缓存

4. 请求本地域名服务器（LDNS），80%的域名解析到这里就完成了

5. 根服务器：本地服务器找不到之后，就要向根服务器发出请求，进行递归查询

十四、DNS 解析过程以及 DNS 劫持

DNS查询的过程简单描述就是：主机首先查询本地是否有DNS映射缓存，如果没有则向本地域名服务器发起某个域名的DNS查询请求，如果本地域名服务器查询到对应IP，就返回结果，否则本地域名服务器向上一级DNS服务器发出查询请求，如果查不到就一直重复这个过程，直到达到根域名服务器。

十五、说一说 TCP 的 keepalive，以及和 HTTP 的 keepalive 的区别？

1. HTTP Keep-Alive在http早期，每个http请求都要求打开一个tpc socket连接，并且使用一次之后就断开这个tcp连 接。使用keep-alive可以改善这种状态，即在一次TCP连接中可以持续发送多份数据而不会断开连接。通过使用 keep-alive机制，可以减少tcp连接建立次数，也意味着可以减少TIME_WAIT状态连接，以此提高性能和提高 httpd服务器的吞吐率(更少的tcp连接意味着更少的系统内核调用,socket的accept()和close()调用)。但是，keep alive并不是免费的午餐,长时间的tcp连接容易导致系统资源无效占用。配置不当的keep-alive，有时比重复利用连接带来的损失还更大。所以，正确地设置keep-alive timeout时间非常重要。

2. TCP KEEPALIVE链接建立之后，如果应用程序或者上层协议一直不发送数据，或者隔很长时间才发送一次数 据，当链接很久没有数据报文传输时如何去确定对方还在线，到底是掉线了还是确实没有数据传输，链接还需不需要保持，这种情况在TCP协议设计中是需要考虑到的。TCP协议通过一种巧妙的方式去解决这个问题，当超过 一段时间之后，TCP自动发送一个数据为空的报文给对方，如果对方回应了这个报文，说明对方还在线，链接可 以继续保持，如果对方没有报文返回，并且重试了多次之后则认为链接丢失，没有必要保持链接。

3. TCP的keepalive机制和HTTP的keep-alive机制是说的完全不同的两个东西，tcp的keepalive是在ESTABLISH状态的时候，双方如何检测连接的可用行。而http的keep-alive说的是如何避免进行重复的TCP三次握手和四次挥手的环节

十六、简述 TCP 协议的延迟 ACK 和累计应答

1. 延迟应答指的是：TCP在接收到对端的报文后，并不会立即发送ack，而是等待一段时间发送ack，以便将ack和要发送的数据一块发送。当然ack不能无限延长，否则对端会认为包超时而造成报文重传。linux采用动态调节算 法来确定延时的时间。

2. 累计应答指的是：为了保证顺序性，每一个包都有一个ID（序号），在建立连接的时候，会商定起始的ID是多少，然后按照ID一个个发送。而为了保证不丢包，对应发送的包都要进行应答，但不是一个个应答，而是应答一个ID表示它之前的包全都收到了，该模式称为累计应答。

。

十七、http每个版本的区别

1）http0.9

最初版本，只支持GET请求，没有请求头和响应头概念。仅能请求访问HTML格式的资源。局限性很强。

2）http1.0

请求方式新增了POST, DELETE, PUT, HEADER

增添了请求头和响应头 包含头信息（HTTP header）和其他元信息，包括状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）

支持图片，视频，二进制代码传输。

根据Content-Type可以支持多种数据格式，支持image，text等格式。

服务器连接后，立即断开tcp连接 无法保持长连接，每次发送请求，都需要进行一次tcp连接（即3次握手4次挥手），使得网络的利用率非常低。

无连接带来的问题：

1. 队头阻塞：前一个请求收到响应之后，再发送下一个请求。如果前一个请求非常耗时则发生阻塞。后面请求回=会一直处于等待状态，获取不到资源

2. 无法复用：发送相同请求需要重新建立一个tcp请求，经过三次握手四次挥手后，服务器返回结果。导致不必要的网络资源浪费。

3）http1.1

长连接:发送相同请求不需要重新建立一个tcp请求，服务器直接返回结果，设置keeplive

管道化:无需等上一个连接响应，下一请求发送。但响应结果必须按照顺序。无法解决队头阻塞。

缓存处理:设置字段cache-control来控制缓存，如有发送请求的时候，如有缓存，直接返回结果。

断点传输:在上传/下载资源时，如果资源过大，将其分割为多个部分，分别上传/下载，如果遇到网络故障，可以从已经上传/下载好的地方继续请求，不用从头开始，提高效率

4）http2.0

二进制分帧:一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"（frame）：头信息帧和数据帧。
帧带来的好处:解析速度快，提高传输效率

多路复用:在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应，这样就避免了"队头堵塞"。
例如：请求A->请求B->响应B->响应A

头部压缩:由于建立的是无状态的，每次都需带头部信息。造成网络资源大量浪费
一方面：客户端和服务器同时维护一张头信息表，，所有字段都会存入这个表，生成一个索引号。每次传输只需要传输索引号。即可。
另一方面：头信息使用gzip或compress压缩后再发送

服务器推送:HTTP/2 允许服务器未经请求，主动向客户端发送资源

十九、http 和 https 的区别

HTTPS，是以安全为目标的HTTP通道，在HTTP的基础上通过身份认证和传输加密阶段保证了传输过 程的安全性。

HTTPS 在HTTP 的基础下加入TLS（Transport Layer Security 安全传输层协议）/SSL（Secure Sockets Layer 安全套接层协议），HTTPS 的安全基础是 TLS/SSL，因此加密就需要TLS/ SSL。HTTPS的特点是：内容加密、身份验证、数据完整性。

加分回答

HTTPS（Hyper Text Transfer Protocol over SecureSocket Layer），是以安全为目标的HTTP通道，在HTTP的基础上通过身份认证和传输加密阶段保证了传输过程的安全性。HTTPS 在HTTP 的基础下加入TLS（Transport Layer Security 安全传输层协议）/SSL（Secure Sockets Layer 安全套接层协议），HTTPS 的安全基础是 TLS/SSL，因此加密就需要TLS/ SSL。 SSL的全称为Secure SocketsLayer，安全套接层协议。是为网络通信提供安全及数据完整性的一种安全协议。SSL协议在1994年被Netscape发明，后来各个浏览器均支持SSL。 TLS的全称是Transport Layer Security，安全传输层协议。是SSL3.0的后续版本。在TLS与SSL3.0之间存在着显著的差别，主要是它们所支持的加密算法不同，所以TLS与SSL3.0不能互操作。虽然TLS与SSL3.0在加密算法上不同，但是在我们理解HTTPS的过程中，我们可以把SSL和TLS看做是同一个协议。 在HTTPS数据传输的过程中，需要用TLS/SSL对数据进行加密，然后通过HTTP对加密后的密文进行传输，可以看出HTTPS的通信是由HTTP和TLS/SSL配合完成的。

HTTPS(全称：Hypertext Transfer Protocol over Secure Socket Layer)，是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。 它是一个URI scheme(抽象标识符体系)，句法类同http:体系。用于安全的HTTP数据传输。

https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层(在HTTP与TCP之间)。这个系统的最初研发由网景公司进行，提供了身份验证与加密通讯方法，现在它被广泛用于万维网上安全敏感的通讯。

超文本传输协议 (HTTP-Hypertext transfer protocol) 是一种详细规定了浏览器和万维网服务器之间互相通信的规则，通过因特网传送万维网文档的数据传送协议。 https协议需要到ca申请证书，一般免费证书很少，需要交费。

HTTPS的特点：

1. 内容加密：混合加密方式，对称加密和非对称加密。

2. 验证身份：通过证书认证客户端访问的是正确的服务器。

3. 数据完整性：防止传输的数据被中间人篡改。

HTTP和HTTPS的不同点总结如下：

• HTTP是基于TCP的，而HTTPS是基于TLS的

• HTTP的往返时间为1RTT，而HTTPS的往返时间为3RTT

• HTTP只需要创建一次TCP连接，而HTTPS需要创建两次TCP连接

• HTTP的默认端口号为80，而HTTPS的默认端口号为443

• HTTP的安全性很差，而HTTPS的安全性比较强

加分回答 HTTPS虽然在安全方面有很大的优势，但是缺点也很明显，如下：

• HTTPS握手阶段耗费时间，几乎是HTTP的数倍，会延长页面的首次绘制时间和增加耗电

• HTTPS的效率没有HTTP高，如果部分数据内容实际上并不需要加密，会平白浪费计算机资源

• HTTPS的证书需要购买，功能越强大的证书价格更高

• HTTPS的加密并不能阻止某些网络攻击，如黑客攻击、拒绝服务攻击等

二十、https的握手过程（简化版）

为了兼顾安全与效率，同时使用了对称加密和非对称加密，对数据进行对称加密，对称加密所要使用 的密钥通过非对称加密传输。

HTTPS协议加密的过程可以分为两个阶段，分别是：

• 证书的认证阶段：使用非对称加解密算法对数据传送阶段的对称加解密密钥进行加密和解密。

• 数据传送阶段：通过证书认证阶段获取到目标服务器的对称加解密密钥，对数据进行加密传送给服务

器。

加分回答

在整个HTTPS数据传输的过程中一共会涉及到四个密钥：

1. CA机构的公钥，用来验证数字证书是否可信任
2. 服务器端的公钥
3. 服务器端的私钥
4. 客户端生成的随机密钥

一个HTTPS请求可以分为两个阶段，证书认证阶段和数据传送阶段。

又可以细分为六个步骤：

1. 客户端第一次向服务器发起HTTPS请求，连接到服务器的443（默认）端口。

2. 服务器端有一个密钥对，公钥和私钥。用来进行非对称加密使用，服务器端保存私钥，不能泄露，公钥可以发送给任何人。服务器将自己的数字证书（包含公钥）发送给客户端。

3. 客户端收到服务器端的数字证书之后，会对数字证书进行检查，验证合法性。如果发现数字证书有问题，那么HTTPS传输就中断。如果数字证书合格，那么客户端生成一个随机值，这个随机值是数据传输阶段时给数据对称加密的密钥，然后用数字证书中的公钥加密这个随机值密钥，这样就生成了加密数据使用的密钥的密文。到这时，HTTPS中的第一次HTTP请求就结束了。

4. 客户端第二次向服务器发起HTTP请求，将对称加密密钥的密文发送给服务器。

5. 服务器接收到客户端发来的密文之后，通过使用非对称加密中的私钥解密密文，得到数据传送阶段使用的对称加密密钥。然后对需要返回给客户端的数据通过这个对称加密密钥加密，生成数据密文，最后将这个密文发送给客户端。

6. 客户端收到服务器端发送过来的密文，通过本地密钥对密文进行解密，得到数据明文。到这时，HTTPS中的第二次HTTP请求结束，整个HTTPS传输完成。

二十一、请你说说对称加密和非对称加密

• 对称加密：对称加密指的就是加密和解密使用同一个秘钥，所以叫做对称加密。对称加密只有一个秘 钥，作为私钥。常见的对称加密算法有：DES、AES、3DES等。

• 非对称加密：非对称加密指的是：加密和解密使用不同的秘钥，一把作为公开的公钥，另一把作为私钥。公钥加密的信息，只有私钥才能解密。常见的非对称加密算法：RSA，ECC等。

加分回答

对称加密和非对称加密相比安全性低，因为加密和解密是同一个密钥，数据包被拦截之后不安全。而非对称加密中，公钥用来加密，私钥用来解密。公钥可以公开给任何用户进行加密，私钥永远在服务器或某个客户端手里，非常安全，数据被拦截也没用，因为私钥未公开就永远无法打开数据包。

二十二、DNS 解析过程以及 DNS 劫持

DNS查询的过程简单描述就是：主机首先查询本地是否有DNS映射缓存，如果没有则向本地域名服务

器发起某个域名的DNS查询请求，如果本地域名服务器查询到对应IP，就返回结果，否则本地域名服

务器向上一级DNS服务器发出查询请求，如果查不到就一直重复这个过程，直到达到根域名服务器。

将查询到的结果缓存到各级DNS服务器，最终返回给主机。如何人为干预域名解析？

1 在/etc/hosts文件中添加，如 192.168.188.1 www.baidu.com

DNS劫持：

在完成整个域名解析的过程之后，并没有收到本该收到的IP地址，而是接收到了一个错误的IP地址。比如输入的网址是百度，但是却进入了奇怪的网址，并且地址栏依旧是百度。在这个过程中，攻击者一般是修改了本地路由器的DNS地址，从而访问了一个伪造的DNS服务器，这个伪造的服务器解析域名的时候返回了一个攻击者精心设计的网站，这个网站可能和目标网站一模一样，当用户输入个人账户时，数据会发送给攻击者，从而造成个人财产的丢失。

预防DNS劫持可以通过以下几种方法：

1. 准备多个域名，当某个域名被劫持时，暂时使用另一个

2. 手动修改自己路由器的DNS地址

3. 修改路由器密码

二十三、http 状态码介绍一下

1. 2xx状态码：操作成功。200 OK
2. 3xx状态码：重定向。301 永久重定向；302暂时重定向
3. 4xx状态码：客户端错误。400 Bad Request；401 Unauthorized；403 Forbidden；404 Not Found；
4. 5xx状态码：服务端错误。500服务器内部错误；501服务不可用

二十四、HTTP建立连接过程

1. 客户机与服务器通过Socket建立网络连接。
2. 建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。
3. 服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。
4. 客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户机与服务器断开连接。

二十五、tcp 和 udp 报文的区别：

TCP首部格式

16位端口号 (port number): 告知主机该报文段是来自哪里 (源端口) 以及传给哪个上层协议或应用程序(目的端口)的,进行TCP通信时,客户端通常使用系统自动选择的临时端口号,而服务器则使用知名服务端口号.所有知名服务使用的端口号都定在/etc/services 文件中

32位序号 (sequence number): 一次TCP通信 (从TCP连接建立到断开) 过程中某一个传输方向上的字节流的每个字节的编号.假设主机A和主机B进行TCP通信,A发送给B的第一个TCP报文段中, 序号值被系统初始化为某个随机值ISN (初始序号值). 那么在该传输方向上(从A到B), 后续的TCP报文段中序号值将被系统设置成ISN 加上该报文段所携带数据的第一个字节在整个字节流中的偏移.例如,某个TCP报文段传送的数据是字节流中的第1025~2048字节,那么该报文段的序号值就是ISN+1025.另外一个传输方向(从B到A)的TCP报文段的序号值也具有相同的含义.

32位确认号 (acknowledgement number): 用作对另一方发送来的TCP报文段的响应.其值是收到的TCP报文段的序号值加1.假设主机A和主机B进行TCP通信,那么A发送出的TCP报文段不仅携带自己的序号,而且包含对B发送来的TCP报文段的确认号.反之,B发送出的TCP报文段也同时携带自己的序号和对A发送来的报文段的确认号.

4位头部长度 (header length): 标识该TCP头部有多少个32bit字 (4字节). 因为4位最大能表示15,所以TCP头部最长是60字节.

6位标志位：

URG 表示紧急指针 (urgent pointer) 是否有效.

ACK 表示确认号是否有效. 我们称携带ACK标志的 TCP报文段为确认报文段.

(确认 ACK ：当 ACK=1 时确认号字段有效，否则无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1) PSH 提示接收端应用程序应该立即从 TCP接收缓冲区中读走数据,为接收后续数据腾出空间 (如果应 用程序不将接收到的数据 读 走, 它们就会一直停留在TCP接收缓冲区中).

RST 表示要求对方重新建立连接.我们称携带RST标志的 TCP报文段为复位报文段.

SYN 表示请求建立一个连接. 我们称携带 SYN 标志的TCP报文段为同步报文段.

(同步 SYN ：在连接建立时用来同步序号。当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中 SYN=1，ACK=1)

F I N 表示通知对方本端要关闭连接了.我们称携带FIN标志的TCP报文段为结束报文段.

(终止 FIN ：用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接)

16位窗口大小(window size):是TCP流量控制的一个手段。
这里说的窗口，指的是接收通告窗口(Receiver Window, RWND).它告诉对方本端的TCP接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度。

16位校验和(TCP checksum):由发送端填充，接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。注意，这个校验不仅包括TCP头部，也包括数据部分。这也是TCP可靠传输的一个重要保障。

16位紧急指针(urgent pointer):是一个正的偏移量。它和序号字段的值相加表示最后-一个紧急数据的下字节的序号。因此，确切地说，这个字段是紧急指针相对当前序号的偏移，不妨称之为紧急偏移。TCP的紧急指针是发送端向接收端发送紧急数据的方法。

UDP首部格式

首部字段只有 8 个字节，包括源端口、目的端口、长度、检验和。

12 字节的伪首部是为了计算检验和临时添加的。

序号，确认号，数据偏移，标识符，窗口大小等

二十六、tcp 粘包

1.什么是TCP粘包问题？

TCP粘包就是指发送方发送的若干包数据到达接收方时粘成了一包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾，出现粘包的原因是多方面的，可能是来自发送方，也可能是来自接收方。

2.造成TCP粘包的原因

1) 发送方原因

TCP默认使用Nagle算法（主要作用：减少网络中报文段的数量），而Nagle算法主要做两件事：

只有上一个分组得到确认，才会发送下一个分组 收集多个小分组，在一个确认到来时一起发送 Nagle算法造成了发送方可能会出现粘包问题

2) 接收方原因

TCP接收到数据包时，并不会马上交到应用层进行处理，或者说应用层并不会立即处理。实际上，TCP将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。这样一来，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

3.什么时候需要处理粘包现象？

如果发送方发送的多组数据本来就是同一块数据的不同部分，比如说一个文件被分成多个部分发送，这时当然不需要处理粘包现象 如果多个分组毫不相干，甚至是并列关系，那么这个时候就一定要处理粘包现象了

4.如何处理粘包现象？

（1）发送方

对于发送方造成的粘包问题，可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭算法。

（2）接收方

接收方没有办法来处理粘包现象，只能将问题交给应用层来处理。

（2）应用层

应用层的解决办法简单可行，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。

解决办法：循环处理，应用程序从接收缓存中读取分组时，读完一条数据，就应该循环读取下一条数据，直到所有数据都被处理完成，但是如何判断每条数据的长度呢？

格式化数据：每条数据有固定的格式（开始符，结束符），这种方法简单易行，但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。 发送长度：发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置。

5. UDP会不会产生粘包问题呢？

TCP为了保证可靠传输并减少额外的开销（每次发包都要验证），采用了基于流的传输，基于流的传输不认为消息是一条一条的，是无保护消息边界的（保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息）。

UDP则是面向消息传输的，是有保护消息边界的，接收方一次只接受一条独立的信息，所以不存在粘包问题。

举个例子：有三个数据包，大小分别为2k、4k、6k，如果采用UDP发送的话，不管接受方的接收缓存有多大，我们必须要进行至少三次以上的发送才能把数据包发送完，但是使用TCP协议发送的话，我们只需要接受方的接收缓存有12k的大小，就可以一次把这3个数据包全部发送完毕。

二十七、http 报文介绍

http 报文头和报文体分隔符是什么？

\r \n 回车、换行

二十八、DNS 过程：

二十四、说说 Cookie 和 Session 的关系和区别是什么

1. Cookie与Session都是会话的一种方式。它们的典型使用场景比如“购物车”，当你点击下单按钮时，服务端并不清楚具体用户的具体操作，为了标识并跟踪该用户，了解购物车中有几样物品，服务端通过为该用户创Cookie/Session来获取这些信息。

2. cookie数据存放在客户的浏览器上，session数据放在服务器上。

3. cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗 考虑到安全应当使用session。

4. session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能 考虑到减轻服务器性能方面，应当使用COOKIE。

5. 单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

二十五、 HTTP 的方法有哪些

1. GET： 用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器

2. POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。

3. PUT： 传输文件，报文主体中包含文件内容，保存到对应URI位置。

4. HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。

5. DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。

6. OPTIONS：查询相应URI支持的HTTP方法

GET与POST的区别？

1. GET是幂等的，即读取同一个资源，总是得到相同的数据，POST不是幂等的；

2. GET一般用于从服务器获取资源，而POST有可能改变服务器上的资源；

3. 请求形式上：GET请求的数据附在URL之后，在HTTP请求头中；POST请求的数据在请求体中；

4. 安全性：GET请求可被缓存、收藏、保留到历史记录，且其请求数据明文出现在URL中。POST的参数不会被保存，安全性相对较高；

5. GET只允许ASCII字符，POST对数据类型没有要求，也允许二进制数据；

6. GET的长度有限制（操作系统或者浏览器），而POST数据大小无限制

二十六、什么是ARP协议 (Address Resolution Protocol)？

ARP协议完成了IP地址与物理地址的映射。每一个主机都设有一个 ARP 高速缓存，里面有所在的局域网上的各主机和路由器的 IP 地址到硬件地址的映射表。当源主机要发送数据包到目的主机时，会先检查自己的ARP高速缓存中有没有目的主机的MAC地址，如果有，就直接将数据包发到这个MAC地址，如果没有，就向所在的局域网发起一个ARP请求的广播包（在发送自己的 ARP 请求时，同时会带上自己的 IP 地址到硬件地址的映射），收到请求的主机检查自己的IP地址和目的主机的IP地址是否一致，如果一致，则先保存源主机的映射到自己的ARP缓存，然后给源主机发送一个ARP响应数据包。源主机收到响应数据包之后，先添加目的主机的IP地址与MAC地址的映射，再进行数据传送。如果源主机一直没有收到响应，表示ARP查询失败。

如果所要找的主机和源主机不在同一个局域网上，那么就要通过 ARP 找到一个位于本局域网上的某个路由器的硬件地址，然后把分组发送给这个路由器，让这个路由器把分组转发给下一个网络。剩下的工作就由下一个网络来做。

二十七、什么是NAT (Network Address Translation, 网络地址转换)？

用于解决内网中的主机要和因特网上的主机通信。由NAT路由器将主机的本地IP地址转换为全球IP地址，分为静态转换（转换得到的全球IP地址固定不变）和动态NAT转换。

二十八、介绍 socket

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。应用程序可以通过它发送或接收数据，可对其进行像对文件一样的打开、读写和关闭等操作。套接字允许应用程序将I/O插入到网络中，并与网络中的其他应用程序进行通信。Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。

小问题：

1.服务端给客户端发送123个报文，收到了3的ack，下一步发哪一个报文：

ack3是对2号报文的确认，所以接下来应该发送3号报文。

2.802.3x 工作在几层：

数据链路层

3.TCP 的 shutdown和close？：

close 会关闭连接，并释放所有连接对应的资源，而 shutdown 并不会释放掉套接字和所有的资源。

close 存在引用计数的概念，并不一定导致该套接字不可用；shutdown 则不管引用计数，直接使得该套接字不可用，如果有别的进程企图使用该套接字，将会受到影响。

close 的引用计数导致不一定会发出 FIN 结束报文，而 shutdown 则总是会发出 FIN 结束报文，这在我们打算关闭连接通知对端的时候，是非常重要的。

4.服务器server怎么把cookie设置到浏览器的：

服务器端像客户端发送Cookie是通过HTTP响应报文实现的

5.https中ssl的握手过程、为什么不一直用非对称加密

HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。

非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的。

6.网络通信中的端口号用来干什么的？

识别进程