1. OSI与TCP/IP 模型
2. 常见网络服务分层
3. TCP三次握手
4. 四次挥手过程：
5. 为什么连接的时候是三次握手，关闭的时候却是四次握手?
6. 如何查看TIME-WAIT状态的链接数量？
7. 为什么会TIME-WAIT过多？解决方法是怎样的？
8. 半连接，洪泛攻击问题以及如何解决（syn_cookie）
9. 为什么客户端的TIME-WAIT状态必须等待2MSL ?
10. 4g切换wifi会发生什么
11. TCP与UDP区别及场景
12. TCP滑动窗口，拥塞控制
13. TCP粘包原因和解决方法
14. TCP、UDP报文格式
15. TCP协议如何保证可靠传输机制？
16. TCP的滑动窗口?
17. 详细讲一下拥塞控制? 为何要进行拥塞控制？
18. TCP拥塞控制4种算法
1. HTTP协议1.0 1.1 2.0
2. HTTP1.0和HTTP1.1的主要区别如下：
3. HTTP1.1和HTTP2.0的主要区别：
4. HTTP和 HTTPS的区别：
5. HTTPS 的缺点：
6. HTTPS链接建立的过程：
7. HTTP常见响应状态码
8. 状态码301和302的区别是什么?
9. 对称加密算法与非对称加密算法的区别
10. HTTP请求方法：
11. Get和Post请求区别
12. GET 和 POST 方法都是安全和幂等的吗？
13. 重定向和转发区别
14. Cookie和Session区别
15. 浏览器输入URL过程
16. DNS协议是TCP还是UDP?
17. ARP协议如何找到对应IP地址和mac的映射的
18. RARP 协议你知道是什么吗？
19. 什么是DDos攻击?
20. 什么是XSS攻击?
21. SQL注入是什么，如何避免SQL注入?
22. 网络编程socket，客户端和服务端通信过程，分别调用了哪些函数，作用是什么
23. 负载均衡算法有哪些?

“知其然，知其所以然。最近看了《图解HTTP》、《图解TCPIP》、《小林coding》和谢希仁的《计算机网络》顺带做了一点笔记。

基础知识

1. OSI与TCP/IP 模型

OSI七层：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层

TCP/IP五层：物理层、数据链路层、网络层、传输层、应用层

七层网络体系结构各层的主要功能：

应用层：为应用程序提供交互服务。在互联网中的应用层协议很多，如域名系统 DNS ，支持万维网应用的 HTTP 协议，支持电子邮件的 SMTP 协议等。
表示层：主要负责数据格式的转换，如加密解密、转换翻译、压缩解压缩等。
会话层：负责在网络中的两节点之间建立、维持和终止通信，如服务器验证用户登录便是由会话层完成的。
运输层：有时也译为传输层，向主机进程提供通用的数据传输服务。该层主要有以下两种协议:
- TCP ：提供面向连接的、可靠的数据传输服务;
- UDP ：提供无连接的、尽最大努力的数据传输服务，但不保证数据传输的可靠性。
网络层：选择合适的路由和交换结点，确保数据及时传送。主要包括 IP 协议。
数据链路层：数据链路层通常简称为链路层。将网络层传下来的 IP 数据包组装成帧，并再相邻节点的链路上传送帧。
物理层：实现相邻节点间比特流的透明传输，尽可能屏蔽传输介质和通信手段的差异。

2. 常见网络服务分层

应用层：

HTTP

、

DNS

、

FTP

、

SMTP

传输层：

TCP

、

UDP

网络层：

IP

、

ICMP

、路由器、防火墙

数据链路层：网卡、网桥、交换机

物理层：中继器、集线器

3. TCP三次握手

三次握手过程：

客户端——发送带有 SYN 标志的数据包——服务端一次握手客户端进入 syn_sent 状态
服务端——发送带有 SYN/ACK 标志的数据包——客户端二次握手服务端进入 syn_rcvd
客户端——发送带有 ACK 标志的数据包——服务端三次握手连接就进入 Established 状态

为什么三次：主要是为了建立可靠的通信信道，保证客户端与服务端同时具备发送、接收数据的能力。

为什么两次不行？

防止已失效的请求报文又传送到了服务端，建立了多余的链接，浪费资源。
两次握手只能保证单向连接是畅通的。（为了实现可靠数据传输， TCP 协议的通信双方，都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤；如果只是两次握手，至多只有连接发起方的起始序列号能被确认，另一方选择的序列号则得不到确认）。

4. 四次挥手过程：

客户端——发送带有 FIN 标志的数据包——服务端，关闭与服务端的连接，客户端进入 FIN-WAIT-1 状态
服务端收到这个 FIN ，它发回⼀个 ACK ，确认序号为收到的序号加 1 ，服务端就进入了 CLOSE-WAIT 状态
服务端——发送⼀个 FIN 数据包——客户端，关闭与客户端的连接，客户端就进入 FIN-WAIT-2 状态
客户端收到这个 FIN ，发回 ACK 报⽂确认，并将确认序号设置为收到序号加 1 ，客户端进入 TIME-WAIT 状态

为什么四次：因为需要确保客户端与服务端的数据能够完成传输。

CLOSE-WAIT：这种状态的含义其实是表示在等待关闭。

TIME-WAIT：为了解决网络的丢包和网络不稳定所带来的其他问题，确保连接方能在时间范围内，关闭自己的连接。

5. 为什么连接的时候是三次握手，关闭的时候却是四次握手?

服务器在收到客户端的

FIN

报文段后，可能还有一些数据要传输，所以不能马上关闭连接，但是会做出应答，返回

ACK

报文段。

接下来可能会继续发送数据，在数据发送完后，服务器会向客户端发送

FIN

报文，表示数据已经发送完毕，请求关闭连接。服务器的

ACK

和

FIN

一般都会分开发送，从而导致多了一次，因此一共需要四次挥手。

6. 如何查看TIME-WAIT状态的链接数量？

netstat -an | grep TIME_WAIT | wc -l  //查看连接数等待time_wait状态连接数

复制

7. 为什么会TIME-WAIT过多？解决方法是怎样的？

可能原因：高并发短连接的

TCP

服务器上，当服务器处理完请求后立刻按照主动正常关闭连接

解决：负载均衡服务器；Web服务器首先关闭来自负载均衡服务器的连接

8. 半连接，洪泛攻击问题以及如何解决（syn_cookie）

在三次握手的过程中，服务器为了响应一个受到的

SYN

报文段，会分配并初始化连接变量和缓存，然后服务器发送一个

SYN/ACK

报文段进行响应，并等待客户端的

ACK

报文段。如果客户不发送

ACK

来完成该三次握手的第三步，最终(通常在一分多钟之后)服务器将终止该半开连接并回收资源。这种

TCP

连接管理协议的特性就会有这样一个漏洞，攻击者发送大量的

TCP SYN

报文段，而不完成第三次握手的步骤。随着这种

SYN

报文段的不断到来，服务器不断为这些半开连接分配资源，从而导致服务器连接资源被消耗殆尽。这种攻击就是

SYN

泛供攻击。

为了应对这种攻击，现在有一种有效的防御系统，称为SYN cookie。SYN cookie的工作方式如下：

当服务器接收到一个 SYN 报文段时，它并不知道该报文段是来自一个合法的用户，还是这种SYN洪泛攻击的一部分。因为服务器不会为该报文段生成一个半开的连接。相反，服务器生成一个初始 TCP 序列号，该序列号是SYN报文段的源IP地址和目的IP地址，源端口号和目的端口号以及仅有服务器知道的秘密数的复杂函数(散列函数)。这种精心制作的初始序列号称为为“cookie”。服务器则发送具有这种特殊初始序号的 SYN/ACK 报文分组。服务器并不记忆该cookie或任何对应于SYN的其他状态信息。
如果该客户是合法的，则它将返回一个 ACK 报文段。当服务器收到该 ACK 报文段，需要验证该ACK是与前面发送的某个 SYN 相对应。由于服务器并不维护有关 SYN 报文段的记忆，所以服务器通过使用 SYN/ACK 报文段中的源和目的IP地址与端口号以及秘密数运行相同的散列函数。如果这个函数的结果(cookie值)加1和在客户的ACK报文段中的确认值相同的话，那么服务器就会认为该 ACK 对应于较早的 SYN 报文段，因此它是合法的。服务器则会生成一个套接字的全开连接。
另一方面，如果客户没有返回一个 ACK 报文段，说明之前的 SYN 报文段是洪泛攻击的一部分，但是它并没有对服务器产生危害，因为服务器没有为它分配任何资源。

9. 为什么客户端的TIME-WAIT状态必须等待2MSL ?

主要有两个原因:

为了保证客户端发送的最后一个ACK报文段能够达到服务器。这个 ACK 报文段可能丢失，因而使处在 LAST-ACK 状态的服务器收不到确认。服务器会超时重传 FIN+ACK 报文段，客户端就能在2MSL时间内收到这个重传的 FIN+ACK 报文段，接着客户端重传一次确认，重启计时器。最好，客户端和服务器都正常进入到 CLOSED 状态。如果客户端在 TIME-WAIT 状态不等待一段时间，而是再发送完 ACK 报文后立即释放连接，那么就无法收到服务器重传的 FIN+ACK 报文段，因而也不会再发送一次确认报文。这样，服务器就无法按照正常步骤进入 CLOSED 状态。
防止已失效的连接请求报文段出现在本连接中。客户端在发送完最后一个 ACK 确认报文段后，再经过时间 2MSL ，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

10. 4g切换wifi会发生什么

当移动设备的网络从

4G

切换到

WiFi

时，意味着IP地址变化了，那么必须要断开连接，然后重新连接，而建立连接的过程包含TCP三次握手和TLS四次挥手的时延，以及TCP慢启动的减速过程，给用户的感觉就是突然网络卡顿了一下，所以说，迁移的成本是很高的。

http3是怎么解决连接迁移

HTTP3

中

QUIC

协议没有用四元组的方式来"绑定”连接，而是通过连接ID来标记通信的两个端点，客户端和服务器可以各自选择一组ID来标记自己，因此即使移动设备的网络变化后，导致IP地址变化了，只要仍保有上下文信息(比如连接ID、TLS 密钥等)，就可以"无缝"地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能。

11. TCP与UDP区别及场景

类型	特点	性能	应用过场景	首部字节
TCP	面向连接、可靠、字节流	传输效率慢、所需资源多	文件、邮件传输	20-60
UDP	无连接、不可靠、数据报文段	传输效率快、所需资源少	语音、视频、直播	8个字节

基于TCP的协议：

HTTP

、

FTP

、

SMTP

基于UDP的协议：

RIP

、

DNS

、

SNMP

12. TCP滑动窗口，拥塞控制

TCP通过：应用数据分割、对数据包进行编号、校验和、流量控制、拥塞控制、超时重传等措施保证数据的可靠传输。

拥塞控制目的：为了防止过多的数据注入到网络中，避免网络中的路由器、链路过载。

拥塞控制过程：TCP维护一个拥塞窗口，该窗口随着网络拥塞程度动态变化，通过慢开始、拥塞避免等算法减少网络拥塞的发生。

13. TCP粘包原因和解决方法

TCP粘包是指：发送方发送的若干包数据到接收方接收时粘成一包

发送方原因：

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

收集多个小分组，在一个确认到来时一起发送、导致发送方可能会出现粘包问题

接收方原因：

TCP将接收到的数据包保存在接收缓存里，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

传输层的UDP协议不会发生粘包或者拆包问题 UDP 是基于报文发送的，在 UDP 首部采用了16bit来指示 UDP 数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。
传输层的TCP协议会发生粘包或者拆包问题

原因有以下两点：
1. TCP 是基于字节流的，虽然应用层和传输层之间的数据交互是大小不等的数据块，但是 TCP 把这些数据块仅仅看成一连串无结构的字节流，没有边界；
2. 在 TCP 的首部没有表示数据长度的字段，基于上面两点，在使用 TCP 传输数据时，才有粘包或者拆包现象发生的可能。

解决粘包问题：解决问题的关键在于如何给每个数据包添加边界信息

最本质原因在与接收对等方无法分辨消息与消息之间的边界在哪，通过使用某种方案给出边界，例如：

发送定长包。每个消息的大小都是一样的，接收方只要累计接收数据，直到数据等于一个定长的数值就将它作为一个消息。
包尾加上\r\n标记。 FTP 协议正是这么做的。但问题在于如果数据正文中也含有\r\n，则会误判为消息的边界。
包头加上包体长度。包头是定长的4个字节，说明了包体的长度。接收对等方先接收包体长度，依据包体长度来接收包体。

14. TCP、UDP报文格式

TCP报文格式：

源端口号和目的端口号：

用于寻找发端和收端应用进程。这两个值加上

IP

首部源端IP地址和目的端

IP

地址唯一确定一个

TCP

连接。

序号字段：

序号用来标识从

TCP

发端向

TCP

收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动，则

TCP

用序号对每个字节进行计数。序号是32 bit的无符号数，序号到达 2^32-1后又从0开始。

当建立一个新的连接时，

SYN

标志变1。序号字段包含由这个主机选择的该连接的初始序号ISN（Initial Sequence Number）。该主机要发送数据的第一个字节序号为这个ISN加1，因为

SYN

标志消耗了一个序号

确认序号：

既然每个传输的字节都被计数，确认序号包含发送确认的一端所期望收到的下一个序号。因此，确认序号应当是上次已成功收到数据字节序号加 1。只有

ACK

标志为 1时确认序号字段才有效。发送

ACK

无需任何代价，因为 32 bit的确认序号字段和A C K标志一样，总是TCP首部的一部分。因此，我们看到一旦一个连接建立起来，这个字段总是被设置， ACK标志也总是被设置为1。TCP为应用层提供全双工服务。这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必须保持每个方向上的传输数据序号。

首都长度：

首部长度给出首部中 32 bit字的数目。需要这个值是因为任选字段的长度是可变的。这个字段占4 bit，因此TCP最多有6 0字节的首部。然而，没有任选字段，正常的长度是 20字节。

标志字段：在

TCP

首部中有 6个标志比特，它们中的多个可同时被设置为1。

URG 紧急指针（u rgent pointer）有效
ACK 确认序号有效。
PSH 接收方应该尽快将这个报文段交给应用层。
RST 重建连接。
SYN 同步序号用来发起一个连接。这个标志和下一个标志将在第 1 8章介绍。
FIN 发端完成发送任务。

窗口大小：

TCP

的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端期望接收的字节。窗口大小是一个 16 bit字段，因而窗口大小最大为 65535字节。

检验和：

检验和覆盖了整个的

TCP

报文段：

TCP

首部和

TCP

数据。这是一个强制性的字段，一定是由发端计算和存储，并由收端进行验证。

紧急指针：

只有当

URG

标志置1时紧急指针才有效。紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。

TCP

的紧急方式是发送端向另一端发送紧急数据的一种方式。

选项：

最常见的可选字段是最长报文大小，又称为

MSS

(Maximum Segment Size)。每个连接方通常都在通信的第一个报文段（为建立连接而设置

SYN

标志的那个段）中指明这个选项。它指明本端所能接收的最大长度的报文段。

UDP报文格式：

端口号：

用来表示发送和接受进程。由于

IP

层已经把I P数据报分配给

TCP

或

UDP

（根据I P首部中协议字段值），因此

TCP

端口号由

TCP

来查看，而

UDP

端口号由

UDP

来查看。

TCP

端口号与

UDP

端口号是相互独立的。

长度：

UDP

长度字段指的是

UDP

首部和

UDP

数据的字节长度。该字段的最小值为 8字节（发送一份0字节的

UDP

数据报是 O K）。

检验和：

UDP

检验和是一个端到端的检验和。它由发送端计算，然后由接收端验证。其目的是为了发现

UDP

首部和数据在发送端到接收端之间发生的任何改动。

IP报文格式：普通的IP首部长为20个字节，除非含有可选项字段。

4位版本：目前协议版本号是4，因此IP有时也称作IPV4.

4位首部长度：

首部长度指的是首部占

32bit

字的数目，包括任何选项。由于它是一个4比特字段，因此首部长度最长为60个字节。

服务类型（TOS）：

服务类型字段包括一个

3bit

的优先权字段（现在已经被忽略），

4bit

的TOS子字段和1bit未用位必须置0。

4bit

的TOS分别代表：最小时延，最大吞吐量，最高可靠性和最小费用。4bit中只能置其中1比特。如果所有4bit均为0，那么就意味着是一般服务。

总长度：

总长度字段是指整个IP数据报的长度，以字节为单位。利用首部长度和总长度字段，就可以知道IP数据报中数据内容的起始位置和长度。由于该字段长

16bit

，所以IP数据报最长可达65535字节。当数据报被分片时，该字段的值也随着变化。

标识字段：

标识字段唯一地标识主机发送的每一份数据报。通常每发送一份报文它的值就会加1。

生存时间：

TTL（time-to-live）生存时间字段设置了数据报可以经过的最多路由器数。它指定了数据报的生存时间。TTL的初始值由源主机设置（通常为 3 2或6 4），一旦经过一个处理它的路由器，它的值就减去 1。当该字段的值为 0时，数据报就被丢弃，并发送

ICMP

报文通知源主机。

首部检验和：

首部检验和字段是根据 I P首部计算的检验和码。它不对首部后面的数据进行计算。

ICMP

、

IGMP

、

UDP

和

TCP

在它们各自的首部中均含有同时覆盖首部和数据检验和码。

以太网报文格式：

目的地址和源地址：是指网卡的硬件地址（也叫MAC 地址），长度是48 位，是在网卡出厂时固化的。

数据：

以太网帧中的数据长度规定最小46 字节，最大1500 字节，

ARP

和

RARP

数据包的长度不够46 字节，要在后面补填充位。最大值1500 称为以太网的最大传输单元（

MTU

），不同的网络类型有不同的

MTU

，如果一个数据包从以太网路由到拨号链路上，数据包度大于拨号链路的

MTU

了，则需要对数据包进行分片fragmentation）。

ifconfig

命令的输出中也有“MTU:1500”。注意，

MTU

个概念指数据帧中有效载荷的最大长度，不包括帧首部的长度。

15. TCP协议如何保证可靠传输机制？

TCP主要提供了检验和、序列号/确认应答、超时重传、滑动窗口、拥塞控制和流量控制等方法实现了可靠性传输。

检验和：通过检验和的方式，接收端可以检测出来数据是否有差错和异常，假如有差错就会直接丢弃 TCP 段，重新发送。
序列号/确认应答：序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。 TCP 传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送 ACK 报文,这个 ACK 报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。
超时重传：超时重传是指发送出去的数据包到接收到确认包之间的时间，如果超过了这个时间会被认为是丢包了，需要重传。最大超时时间是动态计算的。
滑动窗口：滑动窗口既提高了报文传输的效率，也避免了发送方发送过多的数据而导致接收方无法正常处理的异常。
拥塞控制：在数据传输过程中，可能由于网络状态的问题，造成网络拥堵，此时引入拥塞控制机制，在保证 TCP 可靠性的同时，提高性能。
流量控制：如果主机A一直向主机B发送数据，不考虑主机B的接受能力，则可能导致主机B的接受缓冲区满了而无法再接受数据，从而会导致大量的数据丢包，引发重传机制。而在重传的过程中，若主机B的接收缓冲区情况仍未好转，则会将大量的时间浪费在重传数据上，降低传送数据的效率。所以引入流量控制机制，主机B通过告诉主机A自己接收缓冲区的大小，来使主机A控制发送的数据量。流量控制与 TCP 协议报头中的窗口大小有关。

16. TCP的滑动窗口?

在进行数据传输时，如果传输的数据比较大，就需要拆分为多个数据包进行发送。

TCP

协议需要对数据进行确认后，才可以发送下一个数据包。这样一来，就会在等待确认应答包环节浪费时间。为了避免这种情况，

TCP

引入了窗口概念。窗口大小指的是不需要等待确认应答包而可以继续发送数据包的最大值。

从上面的图可以看到滑动窗口左边的是已发送并且被确认的分组，滑动窗口右边是还没有轮到的分组。

滑动窗口里面也分为两块，一块是已经发送但是未被确认的分组，另一块是窗口内等待发送的分组。随着已发送的分组不断被确认，窗口内等待发送的分组也会不断被发送。整个窗口就会往右移动，让还没轮到的分组进入窗口内。

可以看到滑动窗口起到了一个限流的作用，也就是说当前滑动窗口的大小决定了当前

TCP

发送包的速率，而滑动窗口的大小取决于拥塞控制窗口和流量控制窗口的两者间的最小值。

17. 详细讲一下拥塞控制? 为何要进行拥塞控制？

A在给B传输数据, A却没有收到B反馈的

TCP

,A就认为B发送的数据包丢失了..进而会重新传输这个丢失的数据包。然而实际情况有可能此时有太多主机正在使用信道资源，导致网络拥塞了。重传数据浪费了资源，所以要进行拥塞控制。发送发不知道一次发多少数据合适，所以设置一个拥塞窗口。

TCP拥塞控制原理是通过：慢启动、拥塞避免、快重传、快启动

发送方维持一个叫做拥塞窗口cwnd (congestion window)的状态变量。当cwndssthresh时，改用拥塞避免算法。

慢开始: 不要一开始就发送大量的数据，由小到大逐渐增加拥塞窗口的大小。
拥塞避免: 拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1而不是加倍。这样拥塞窗口按线性规律缓慢增长。
快重传: 我们可以剔除一些不必要的拥塞报文，提高网络吞吐量。比如接收方在收到一个失序的报文段后就立即发出重复确认，而不要等到自己发送数据时捎带确认。快重传规定:发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
快恢复: 主要是配合快重传。当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半(为了预防网络发生拥塞)，但接下来并不执行慢开始算法，因为如果网络出现拥塞的话就不会收到好几个重复的确认，收到三个重复确认说明网络状况还可以。

18. TCP拥塞控制4种算法

基于丢包的拥塞控制：将丢包视为出现拥塞，采取缓慢探测的方式，逐渐增大拥塞窗口，当出现丢包时，将拥塞窗口减小，如 Reno 、 Cubic 等。
基于时延的拥塞控制：将时延增加视为出现拥塞，延时增加时增大拥塞窗口，延时减小时减小拥塞窗口，如 Vegas 、 FastTCP 等。
基于链路容量的拥塞控制：实时测量网络带宽和时延，认为网络上报文总量大于带宽时延乘积时出现了拥塞，如 BBR 。
基于学习的拥塞控制：没有特定的拥塞信号，而是借助评价函数，基于训练数据，使用机器学习的方法形成一个控制策略，如 Remy 。

HTTP协议

1. HTTP协议1.0 1.1 2.0

HTTP1.0：服务器处理完成后立即断开

TCP

连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）

HTTP1.1：

KeepAlived

长连接避免了连接建立和释放的开销；通过

Content-Length

来判断当前请求数据是否已经全部接受（有状态）

HTTP2.0：引入二进制数据帧和流的概念，其中帧对数据进行顺序标识；因为有了序列，服务器可以并行的传输数据。

无状态的好坏

无状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务。
无状态的坏处，既然服务器没有记忆能力，这样每操作一次，都要验证信息。例如登录->添加购物车->下单->结算->支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要问一遍身份信息。

解决无状态的问题，解法方案有很多种，其中比较简单的方式用

Cookie

和

Session

技术。

2. HTTP1.0和HTTP1.1的主要区别如下：

缓存处理：1.1添加更多的缓存控制策略（如： Entity tag ， If-Match ）
网络连接的优化：1.1支持断点续传
错误状态码的增多：1.1新增了24个错误状态响应码，丰富的错误码更加明确各个状态
Host头处理：支持 Host 头域，不在以 IP 为请求方标志
长连接：减少了建立和关闭连接的消耗和延迟。

3. HTTP1.1和HTTP2.0的主要区别：

新的传输格式：2.0使用二进制格式，1.0依然使用基于文本格式
多路复用：连接共享，不同的 request 可以使用同一个连接传输（最后根据每个 request 上的id号组合成正常的请求）
header压缩：由于1.X中 header 带有大量的信息，并且得重复传输，2.0使用 encoder 来减少需要传输的 hearder 大小
服务端推送：同 google 的 SPDUY （1.0的一种升级）一样

4. HTTP和 HTTPS的区别：

最重要的区别就是安全性， HTTP 明文传输，不对数据进行加密安全性较差。 HTTPS (HTTP + SSL / TLS)的数据传输过程是加密的，安全性较好。
证书：使用 HTTPS 协议需要申请 CA 证书，一般免费证书较少，因而需要一定费用。证书颁发机构如： Symantec 、 Comodo 、 DigiCert 和 GlobalSign 等。
响应速度： HTTP 页面响应速度比 HTTPS 快，这个很好理解，由于加了一层安全层，建立连接的过程更复杂，也要交换更多的数据，难免影响速度。
加密： HTTP 协议运行在 TCP （三次握手）之上，所有传输的内容都是明文， HTTPS 运行在 SSL/TLS 之上， SSL/TLS 运行在 TCP 之上，所有传输的内容都经过加密的。
端口不同： HTTPS 和 HTTP 使用的是完全不同的连接方式，用的端口也不一样，前者是 443 ，后者是 80 。

HTTP	HTTPS
默认端口80	默认端口443
明文传输、数据未加密、安全性较差	传输协议ssl加密、安全性较好
响应速度快，消耗资源少	响应速度慢、消耗资源多，需要用到CA证书

5. HTTPS 的缺点：

在相同网络环境中， HTTPS 相比 HTTP 无论是响应时间还是耗电量都有大幅度上升。
HTTPS 的安全是有范围的，在黑客攻击、服务器劫持等情况下几乎起不到作用。
在现有的证书机制下，中间人攻击依然有可能发生。
HTTPS 需要更多的服务器资源，也会导致成本的升高。

6. HTTPS链接建立的过程：

首先客户端先给服务器发送一个请求
服务器发送一个 SSL 证书给客户端，内容包括：证书的发布机构、有效期、所有者、签名以及公钥
客户端对发来的公钥进行真伪校验，校验为真则使用公钥对对称加密算法以及对称密钥进行加密
服务器端使用私钥进行解密并使用对称密钥加密确认信息发送给客户端
随后客户端和服务端就使用对称密钥进行信息传输

加密流程按图中的序号分为:

客户端请求 HTTPS 网址，然后连接到 server 的443端口( HTTPS 默认端口，类似于 HTTP 的80端口)。
采用 HTTPS 协议的服务器必须要有一套数字 CA (Certification Authority)证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存，不可泄漏。公钥则是附带在证书的信息中，可以公开的。证书本身也附带-一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被篡改。
服务器响应客户端请求，将证书传递给客户端，证书包含公钥和大量其他信息，比如证书颁发机构信息，公司信息和证书有效期等。
客户端解析证书并对其进行验证。如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一一个随机码 KEY ,并使用公钥A将其加密。
客户端把加密后的随机码 KEY 发送给服务器，作为后面对称加密的密钥。
服务器在收到随机码 KEY 之后会使用私钥B将其解密。经过以上这些步骤，客户端和服务器终于建立了安全连接，完美解决了对称加密的密钥泄露问题，接下来就可以用对称加密愉快地进行通信了。
服务器使用密钥(随机码 KEY )对数据进行对称加密并发送给客户端，客户端使用相同的密钥(随机码 KEY )解密数据。
双方使用对称加密愉快地传输所有数据。

7. HTTP常见响应状态码

：Continue 一一继续。客户端应继续其请求。

：OK 一一请求成功。一般用于GET与POST请求。

：Moved Permanently 一一永久重定向。

：Found 一一暂时重定向。

：Bad Request 一一客户端请求的语法错误，服务器无法理解。请求没有包含host头

：Forbideen 一一服务器理解请求客户端的请求，但是拒绝执行此请求。禁止客户访问该资源

：Not Found 一一服务器无法根据客户端的请求找到资源（网页）。资源未找到

：Internal Server Error 一一服务器内部错误，无法完成请求。

：Bad Gateway 一一作为网关或者代理服务器尝试执行请求时，从远程服务器接收到了无效的响应。

8. 状态码301和302的区别是什么?

为永久重定向，

为临时重定向

共同点:

和

状态码都表示重定向，就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取(用户看到的效果就是他输入的地址A瞬间变成了另一个地址B)。

不同点:

表示旧地址A的资源已经被永久地移除了(这个资源不可访问了)，搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址;

表示旧地址A的资源还在(仍然可以访问)，这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。SEO中

好于

。

补充，重定向原因:

网站调整(如改变网页目录结构);
网页被移到一个新地址;
网页扩展名改变(如应用需要把.php改成.Html或.shtml)。

9. 对称加密算法与非对称加密算法的区别

对称加密算法：

双方持有相同的密钥，且加密速度快，典型对称加密算法：

DES

、

AES

非对称加密算法：

密钥成对出现（私钥、公钥），私钥只有自己知道，不在网络中传输；而公钥可以公开。相比对称加密速度较慢，典型的非对称加密算法有：

AES

、

DSA

10. HTTP请求方法：

方法	描述
GET	像特定资源发送请求，查询数据，并返回实体
POST	向指定资源提交数据进行处理，可能会导致新的资源建立、已有的资源修改
PUT	向服务器上传新的内容
HEAD	类似GET请求，返回的响应式中没有具体内容，用于获取报头
DELETE	请求服务器删除指定标识的资源
OPTIONS	可以原来向服务器发送请求来测试服务器的功能性
TRACE	回显服务器收到的请求，用于测试和诊断
CONNECT	HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器

11. Get和Post请求区别

GET	POST
HTTP规范	GET用于信息获取	修改服务器上的资源的请求
可见性	数据在URL中对所有人可见	数据不会显示在URL中
安全性	与post相比，get的安全性较差，因为所发送的数据是URL的一部分	安全，因为参数不会被保存在浏览器历史或web服务器日志中
数据长度	受限制，最长2kb	无限制
编码类型	application/x-www-form-urlencoded	multipart/form-data
缓存	能被缓存	不能被缓存

12. GET 和 POST 方法都是安全和幂等的吗？

先说明下安全和幂等的概念：

在 DSA 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。
所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的。

那么很明显 GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。

POST

因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。

13. 重定向和转发区别

转发是服务器行为,重定向是客户端行为

重定向：redirect：

地址栏发生变化

重定向可以访问其他站点（服务器）的资源

重定向是两次请求。不能使用request对象来共享数据

转发：forward：

转发地址栏路径不变

转发只能访问当前服务器下的资源

转发是一次请求，可以使用

request

对象共享数据

14. Cookie和Session区别

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但两者有所区别：

Cookie

数据保存在客户端(浏览器端)，

Session

数据保存在服务器端。

cookie

不是很安全，别人可以分析存放在本地的

Cookie

并进行欺骗,考虑到安全应当使用session。

Cookie

⼀般⽤来保存⽤户信息，

Session

的主要作⽤就是通过服务端记录⽤户的状态

15. 浏览器输入URL过程

过程：

DNS

解析、

TCP

连接、发送

HTTP

请求、服务器处理请求并返回

HTTP

报文、浏览器渲染、结束

域名解析(域名www.baidu.com变为IP地址)。浏览器搜索自己的 DNS 缓存(维护一张域名与IP的对应表);
1. 若没有，则搜索操作系统的 DNS 缓存(维护一张域名与IP的对应表) ;
2. 若没有，则搜索操作系统的hosts文件(维护一张域名与IP的对应表)。
3. 若都没有，则找TCP/IP参数中设置的首选dns服务器，即本地 DNS 服务器(递归查询)，本地域名服务器查询自己的 DNS 缓存，如果没有，则进行迭代查询。将本地dns服务器将IP返回给操作系统，同时缓存IP。
发起 TCP 的三次握手，建立 TCP 连接。浏览器会以一个随机端口(1024-65535) 向服务端的web程序80端口发起 TCP 的连接。
建立 TCP 连接后发起HTTP请求。
服务器响应 HTTP 请求，客户端得到 html 代码。服务器web应用程序收到 HTTP 请求后，就开始处理请求，处理之后就返回给浏览器 html 文件。
浏览器解析 html 代码，并请求 html 中的资源。
浏览器对页面进行渲染，并呈现给用户。

如何查看 TCP 的连接状态？TCP 的连接状态查看，在 Linux 可以通过 netstat -napt 命令查看。

16. DNS协议是TCP还是UDP?

DNS 占用53号端口，同时使用 TCP 和 UDP 协议。那么 DNS
在什么情况下使用这两种协议？

DNS在区域传输的时候使用TCP协议，其他时候使用UDP协议。
- 客户端向 DNS 服务器查询域名，一般返回的内容都不超过512字节，用 UDP 传输即可。不用经过 TCP 三次握手，这样 DNS 服务器负载更低，响应更快。虽然从理论上说，客户端也可以指定向 DNS 服务器查询的时候使用 TCP ，但事实上，很多 DNS 服务器进行配置的时候，仅支持 UDP 查询包。
- 辅域名服务器会定时（一般3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，会执行一次区域传送，进行数据同步。区域传送使用 TCP 而不是 UDP ，因为数据同步传送的数据量比一个请求应答的数据量要多得多。
- TCP 是一种可靠连接，保证了数据的准确性。
- DNS区域传输的时候使用TCP协议：
- 域名解析时使用UDP协议：

17. ARP协议如何找到对应IP地址和mac的映射的

简单地说，

ARP

是借助

ARP

请求与

ARP

响应两种类型的包确定

MAC

地址的。

主机会通过广播发送 ARP 请求，这个包中包含了想要知道的 MAC 地址的主机 IP 地址。
当同个链路中的所有设备收到 ARP 请求时，会去拆开 ARP 请求包里的内容，如果 ARP 请求包中的目标 IP 地址与自己的 IP 地址一致，那么这个设备就将自己的 MAC 地址塞入 ARP 响应包返回给主机。

操作系统通常会把第一次通过

ARP

获取的

MAC

地址缓存起来，以便下次直接从缓存中找到对应 IP 地址的

MAC

地址。不过，

MAC

地址的缓存是有一定期限的，超过这个期限，缓存的内容将被清除

18. RARP 协议你知道是什么吗？

ARP 协议是已知 IP 地址求

MAC

地址，那

RARP

协议正好相反，它是已知

MAC

地址求 IP 地址。例如将打印机服务器等小型嵌入式设备接入到网络时就经常会用得到。

通常这需要架设一台

RARP

服务器，在这个服务器上注册设备的

MAC

地址及其 IP 地址。然后再将这个设备接入到网络，接着：

该设备会发送一条「我的 MAC 地址是XXXX，请告诉我，我的IP地址应该是什么」的请求信息。
RARP 服务器接到这个消息后返回「 MAC 地址为 XXXX 的设备，IP地址为 XXXX」的信息给这个设备。

最后，设备就根据从

RARP

服务器所收到的应答信息设置自己的 IP 地址

19. 什么是DDos攻击?

DDos

全称Distributed Denial of Service，分布式拒绝服务攻击。最基本的DOS攻击过程如下:

客户端向服务端发送请求链接数据包。
服务端向客户端发送确认数据包。
客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认

DDos

则是采用分布式的方法，通过在网络上占领多台“肉鸡”，用多台计算机发起攻击。

DDos

攻击现在基本没啥作用了，因为服务器的性能都很好，而且是多台服务器共同作用，1V1的模式黑客无法占上风。对于

DDos

攻击，预防方法有:

减少SYN timeout时间。在握手的第三步，服务器会等待30秒-120秒的时间，减少这个等待时间就能释放更多的资源。
限制同时打开的SYN半连接数目。

20. 什么是XSS攻击?

XSS也称cross-sitescripting,跨站脚本。这种攻击是由于服务器将攻击者存储的数据原原本本地显示给其他用户所致的。比如一个存在XSS漏洞的论坛，用户发帖时就可以引入带有< script>标签的代码，导致恶意代码的执行。

预防措施有:

前端：过滤。
后端：转义，比如go自带的处理器就具有转义功能。

21. SQL注入是什么，如何避免SQL注入?

SQL

注入就是在用户输入的字符串中加入

SQL

语句，如果在设计不良的程序中忽略了检查，那么这些注入进去的

SQL

语句就会被数据库服务器误认为是正常的

SQL

语句而运行，攻击者就可以执行计划外的命令或访问未被授权的数据。

SQL

注入的原理主要有以下4点：

恶意拼接查询
利用注释执行非法命令
传入非法参数
添加额外条件

避免

SQL

注入的一些方法：

参数校验：在一些不该有特殊字符的参数中提前进行特殊字符校验即可。
限制数据库权限，给用户提供仅仅能够满足其工作的最低权限。
提供参数化查询接口，不要直接使用原生 SQL 。
SQL预编译

在知道了

SQL

注入的原理之后，我们同样也了解到

MySQL

有预编译的功能，指的是在服务器启动时，

MySQL

Client把

SQL

语句的模板（变量采用占位符进行占位）发送给

MySQL

服务器，

MySQL

服务器对

SQL

语句的模板进行编译，编译之后根据语句的优化分析对相应的索引进行优化，在最终绑定参数时把相应的参数传送给

MySQL

服务器，直接进行执行，节省了

SQL

查询时间，以及

MySQL

服务器的资源，达到一次编译、多次执行的目的，除此之外，还可以防止SQL注入。

具体是怎样防止

SQL

注入的呢？实际上当将绑定的参数传到

MySQL