[网络协议]01-计算机网络

文章后续于https://github.com/zgkaii/CS-Study-Notes更新，欢迎批评指正！

简述一下计算机网络体系结构

计算机网络中有OSI网络分层模型、TCP/IP网络分层模型和五层协议参考模型，其中：

• OSI模型（7层）——理论标准：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。（复杂不适用）
• TCP/IP模型（4层）——事实标准：网络接口层、网际层、运输层、 应用层。（广泛应用）
• 五层协议模型（5层）——学术研究：物理层、数据链路层、网络层、运输层、 应用层。（学习参考）

TCP/IP协议簇如下：

应用层

应用层(application-layer）的任务是通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程（进程：主机中正在运行的程序）间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如域名系统DNS，支持万维网应用的 HTTP协议，支持电子邮件的 SMTP协议等等。我们把应用层交互的数据单元称为报文。

域名系统

域名系统(Domain Name System缩写 DNS，Domain Name被译为域名)是因特网的一项核心服务，它作为可以将域名和IP地址相互映射的一个分布式数据库，能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。（百度百科）例如：一个公司的 Web 网站可看作是它在网上的门户，而域名就相当于其门牌地址，通常域名都使用该公司的名称或简称。例如上面提到的微软公司的域名，类似的还有：IBM 公司的域名是 www.ibm.com、Oracle 公司的域名是 www.oracle.com、Cisco公司的域名是 www.cisco.com 等。

HTTP协议

超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的 WWW（万维网） 文件都必须遵守这个标准。设计 HTTP 最初的目的是为了提供一种发布和接收 HTML 页面的方法。（百度百科）

运输层

运输层(transport layer)的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。由于一台主机可同时运行多个线程，因此运输层有复用和分用的功能。所谓复用就是指多个应用层进程可同时使用下面运输层的服务，分用和复用相反，是运输层把收到的信息分别交付上面应用层中的相应进程。

运输层主要使用以下两种协议:

1. 传输控制协议 TCP（Transmission Control Protocol）–提供面向连接的，可靠的数据传输服务。
2. 用户数据协议 UDP（User Datagram Protocol）–提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）。

网络层

在计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。 在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报 ，简称 数据报。

这里要注意：不要把运输层的“用户数据报 UDP ”和网络层的“ IP 数据报”弄混。另外，无论是哪一层的数据单元，都可笼统地用“分组”来表示。

这里强调指出，网络层中的“网络”二字已经不是我们通常谈到的具体网络，而是指计算机网络体系结构模型中第三层的名称.

互联网是由大量的异构（heterogeneous）网络通过路由器（router）相互连接起来的。互联网使用的网络层协议是无连接的网际协议（Internet Protocol）和许多路由选择协议，因此互联网的网络层也叫做网际层或IP层。

数据链路层

数据链路层(data link layer)通常简称为链路层。两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。 在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。

在接收数据时，控制信息使接收端能够知道一个帧从哪个比特开始和到哪个比特结束。这样，数据链路层在收到一个帧后，就可从中提出数据部分，上交给网络层。

控制信息还使接收端能够检测到所收到的帧中有无差错。如果发现差错，数据链路层就简单地丢弃这个出了差错的帧，以避免继续在网络中传送下去白白浪费网络资源。如果需要改正数据在链路层传输时出现差错（这就是说，数据链路层不仅要检错，而且还要纠错），那么就要采用可靠性传输协议来纠正出现的差错。这种方法会使链路层的协议复杂些。

物理层

在物理层上所传送的数据单位是比特。

物理层(physical layer)的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异， 使其上面的数据链路层不必考虑网络的具体传输介质是什么。“透明传送比特流”表示经实际电路传送后的比特流没有发生变化，对传送的比特流来说，这个电路好像是看不见的。

在互联网使用的各种协中最重要和最著名的就是 TCP/IP 两个协议。现在人们经常提到的TCP/IP并不一定单指TCP和IP这两个具体的协议，而往往表示互联网所使用的整个TCP/IP协议族。

TCP与UDP协议

如果设计一个聊天系统，应该用 TCP 还是 UDP？为什么？

TCP与UDP的区别主要有：

• 用户数据报协议 UDP（User Datagram Protocol）是无连接的，尽最大可能交付，没有拥塞控制，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），支持一对一、一对多、多对一和多对多的交互通信。UDP是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等。（不可靠，无连接，时延小，适用于小文件）
• 传输控制协议 TCP（Transmission Control Protocol）是面向连接（送数据之前必须先建立连接，数据传送结束后要释放连接）的，提供可靠交付，有流量控制，拥塞控制，提供全双工通信，面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块），每一条 TCP 连接只能是点对点的（一对一）。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。（可靠，面向连接，时延大，适用于大文件）

现在的移动端IM、推送系统，既面对移动互联网的不确定性，又面对智能终端频繁的系统休眠、网络切换，还要考虑服务端的承载成本，对于在线服务而言UDP是比TCP更适合的方式。但是由于数据完整性、安全性的需要，又不应完全放弃TCP的可靠与安全。

所以，个人认为，更恰当的方式应该是：两种通信协议同时使用，各有侧重。UDP用于保持大量终端的在线与控制，应用与业务则通过TCP去实现。事实上，这个也是即时通讯巨头QQ所采用的方式。

早期的时候，QQ还是主要使用TCP协议，而后来QQ包含了文本、语音、图片、视频等等消息类型，传统的文本信息显然不是重头戏了，因此实际中QQ使用的协议包含了UDP、TCP、HTTP这三种。

TCP 如何保证传输可靠性?

对于可靠性，TCP 通过以下方式进行保证：

1. 应用数据被分割成 TCP 认为最适合发送的数据块。
2. TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
3. 校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
4. TCP 的接收端会丢弃重复的数据。
5. 流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）
6. 拥塞控制： 当网络拥塞时，减少数据的发送。
7. ARQ协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
8. 超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

ARQ协议

自动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议。

停止等待ARQ协议

停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组。

在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。

优缺点：

• 优点： 简单
• 缺点： 信道利用率低，等待时间长

1) 无差错情况:

发送方发送分组,接收方在规定时间内收到,并且回复确认.发送方再次发送。

2) 出现差错情况（超时重传）:

停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为 自动重传请求 ARQ 。另外在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。连续 ARQ 协议 可提高信道利用率。发送维持一个发送窗口，凡位于发送窗口内的分组可连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组位置的所有分组都已经正确收到了。

3) 确认丢失和确认迟到

• 确认丢失 ：确认消息在传输过程丢失。当A发送M1消息，B收到后，B向A发送了一个M1确认消息，但却在传输过程中丢失。而A并不知道，在超时计时过后，A重传M1消息，B再次收到该消息后采取以下两点措施：1. 丢弃这个重复的M1消息，不向上层交付。 2. 向A发送确认消息。（不会认为已经发送过了，就不再发送。A能重传，就证明B的确认消息丢失）。
• 确认迟到 ：确认消息在传输过程中迟到。A发送M1消息，B收到并发送确认。在超时时间内没有收到确认消息，A重传M1消息，B仍然收到并继续发送确认消息（B收到了2份M1）。此时A收到了B第二次发送的确认消息。接着发送其他数据。过了一会，A收到了B第一次发送的对M1的确认消息（A也收到了2份确认消息）。处理如下：1. A收到重复的确认后，直接丢弃。2. B收到重复的M1后，也直接丢弃重复的M1。

连续ARQ协议

连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

优缺点：

• 优点： 信道利用率高，容易实现，即使确认丢失，也不必重传。
• 缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如：发送方发送了 5条 消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。

什么是 TCP 滑动窗口？

滑动窗口协议，是传输层进行流量控制的一种措施，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，从而达到防止发送方发送速度过快而导致自己被淹没的目的。将窗口字段设置为 0，则发送方不能发送数据。

TCP 的滑动窗口解决了端到端的流量控制问题，允许接受方对传输进行限制，直到它拥有足够的缓冲空间来容纳更多的数据。

什么是拥塞控制？

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

TCP的拥塞控制采用了四种算法，即 慢开始 、 拥塞避免 、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。

• 慢开始： 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍。
• 拥塞避免： 拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送放的cwnd加1.
• 快重传与快恢复：
  在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。 　当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

TCP 三次握手和四次挥手是什么？

三次握手

假设 A 为客户端，B 为服务器端。

• 首先 B 处于 LISTEN（监听）状态，等待客户的连接请求。
• A 向 B 发送连接请求报文，其同步位SYN=1，选择一个初始的序号 seq = x(随机)。
• B 收到连接请求报文，如果同意建立连接，则向 A 发送连接确认报文，SYN=1，确认值ACK=1，确认号为ack=x+1，同时也选择一个初始的序号seq=y(随机)。
• A 收到 B 的连接确认报文后，还要向 B 发出确认，确认号为ack = y+1，序号为seq = x+1。
• B 收到 A 的确认后，连接建立。

ACK 在连接建立之后都为 1。

简化一下三次握手的流程：

刚开始客户端处于 closed 的状态，服务端处于 listen 状态。然后：

• 第一次握手：客户端发送带有 SYN标志的数据包给服务端，指明客户端的初始化序列号 ISN，客户端处于 SYN_SENT 状态。
• 第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)，同时会把客户端的 ISN + 1 作为 ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_RCVD 的状态。
• 第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方以建立起了连接。

三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

第一次握手：客户端什么都不能确认；服务端确认了对方发送正常，自己接收正常；

第二次握手：客户端确认自己发送、接收正常，对方发送、接收正常；服务端确认对方发送正常，自己接收正常；

第三次握手：客户端确认了自己发送、接收正常，对方发送、接收正常；服务端确认了自己发送、接收正常，对方发送、接收正常。

所以三次握手才能确认双方发送与接收功能都正常，缺一不可。

第2次握手传回了ACK，为什么也传回了SYN？

接收端传回发送端所发送的ACK是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。而回传SYN则是为了建立并确认从服务端到客户端的通信。

SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement）消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。

为什么要三次握手？两次握手不行吗？

第三次握手是为了防止SYN泛洪攻击，防止已失效的连接请求到达服务器，让服务器错误打开连接。

• SYN泛洪攻击发生在OSI第四层，这种方式利用TCP协议的特性，就是三次握手。攻击者发送TCP SYN，SYN是TCP三次握手中的第一个数据包，而服务器返回ACK后，该攻击者就不对其进行再确认，那么这个TCP连接就处于挂起状态，也就是半连接状态，服务器收不到再确认的话，就会重复发送ACK给攻击者。这样会浪费服务器的资源。如果有成千上万的这种连接，主机资源将被耗尽，从而达到攻击的目的。

对于SYN泛洪攻击的防范，优化主机系统设置是常用的手段。如降低SYN timeout时间，使得主机尽快释放半连接的占用；又比如采用SYN cookie设置，如果短时间内连续收到某个IP的重复SYN请求，则认为受到了该IP的攻击，丢弃来自该IP的后续请求报文。此外合理地采用防火墙等外部网络安全设施也可缓解SYN泛洪攻击。

四次挥手

假设 A 为客户端，B 为服务器端。

• A 发送连接释放报文，FIN=1，用来关闭客户端到服务器的数据传送。
• 服务器-收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加1，此时 TCP 属于半关闭状态，B 能向 A 发送数据但是 A 不能向 B 发送数据。
• 当 B 不再需要连接时，再发送连接释放报文，FIN=1。
• A 收到后发回 ACK 报文确认，并将确认序号设置为收到序号加1，进入 TIME-WAIT 状态，等待 2 MSL（最大报文存活时间）后释放连接。
• B 收到 A 的确认后释放连接。

和 SYN 一样，一个 FIN 不携带数据，只占用一个序号。

任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。

四次挥手的流程：

刚开始双方都处于 established 状态，假如是客户端先发起关闭请求，则：

• 第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于CLOSED_WAIT1状态。
• 第二次握手：服务端收到 FIN报文后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT2状态。
• 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
• 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态。服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

为什么要四次挥手？

TCP是全双工通信，服务端和客服端都能发送和接收数据。TCP在断开连接时，需要服务端和客服端都确定对方将不再发送数据。

• 第1次挥手：由客户端向服务端发起，服务端收到信息后就能确定客户端已经停止发送数据。

• 第2次挥手：由服务端向客户端发起，客户端收到消息后就能确定服务端已经知道客户端不会再发送数据。

• 第3次挥手：由服务端向客户端发起，客户端收到消息后就能确定服务端已经停止发送数据。

• 第4次挥手：由客户端向服务端发起，服务端收到信息后就能确定客户端已经知道服务端不会再发送数据。

为何一定要等 2MSL ？

客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送 FIN 连接释放报文。

一定要等 2MSL 有两个理由：

• 确保最后一个确认报文能够到达。如果服务端没收到客户端发送来的确认报文，那么就会重新发送连接释放请求报文（FIN+ACK），客户端等待一段时间就是为了处理这种情况的发生。
• 等待一段时间是为了防止已经失效的请求报文段出现在本连接中，确保所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

什么是 TCP 粘包/拆包?有什么解决办法呢？

TCP 粘包/拆包 就是你基于 TCP 发送数据的时候，出现了多个字符串“粘”在了一起或者一个字符串被“拆”开的问题。我们发送两条消息：ABC 和 DEF，可能一次就把两条消息接收完了，即 ABCDEF；也可能分成了好多次，比如 AB、CD 和 EF。

对方一次性接收了多条消息这种现象，我们就称之为粘包现象。

对方多次接收了不完整消息这种现象，我们就称之为拆包（半包）现象。

粘包

TCP 发送消息的时候是有缓冲区的，当消息的内容远小于缓冲区的时候，这条消息不会立马发送出去，而是跟其它的消息合并之后再发送出去，这样合并发送是明显能够提高效率的。但是，对方接收到的消息就是一个粘包，无法有效区分出来到底是几条消息。当然，接收消息也是会通过 TCP 的缓冲区的，如果接收方读取得不及时，也有可能出现粘包现象。

可见，出现粘包的原因无非两种：

• 发送方每次写入数据 < 套接字缓冲区大小
• 接收方读取套接字缓冲区数据不够及时

拆包

类比粘包，如果发送的消息太大，已经超过了缓冲区的大小，这时候就必须拆分发送，也就形成了拆包现象。还有一种情况，网络协议各层是有最大负载的，所以，对应到各种协议它们是有最大发送数据的限制的，这种可以发送的最大数据称作 MTU（Maximum Transmission Unit，最大传输单元）。

可见，出现拆包的原因有两种：

• 发送方写入数据 > 套接字缓冲区大小
• 发送的数据大于协议的 MTU（Maximum Transmission Unit，最大传输单元），必须拆包

本质原因

TCP 是流式协议，消息无边界。（UDP 协议不会出现粘包 / 拆包现象，它的消息是有明确边界的。UDP 像邮寄的包裹，虽然一次运输多个，但每个包裹都有“界限”，一个一个签收， 所以无粘包、半包问题）。

如何解决粘包/拆包？

解决问题的根本手段就是：找出消息的边界。可以通过封装成帧（Framing）的三种方法：

其他方法：

1. TCP 连接改成短连接，一个请求一个短连接，那么建立连接到释放连接之 间的信息即为传输信息。效率低下，不推荐。
2. 例如 JSON 可以看{}是否应已经成对，所以说衡量实际场景，很多是对现有协议的支持。

HTTP协议

什么是HTTP？

HTTP 协议，是 Hyper Text Transfer Protocol（超文本传输协议）的缩写，是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议，它是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。

主要特点如下：

• 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有 GET、HEAD、POST 等等。每种方法规定了客户与服务器联系的类型不同。由于 HTTP 协议简单，使得 HTTP 服务器的程序规模小，因而通信速度很快。

• 数据格式灵活：HTTP 允许传输任意类型的数据对象。正在传输的类型由Content-Type 加以标记。

• 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

  主要指的是不使用 Keep-Alive 机制的情况下。

• 无状态：HTTP 协议是无状态协议。无状态，是指协议对于事务处理没有记忆能力。无状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

  无状态，所以更容易做服务的扩容，支撑更大的访问量。

• 支持 B/S 及 C/S 模式。

HTTP报文中请求头和响应头都有什么信息？

HTTP 协议的请求报文和响应报文的结构基本相同，由三大部分组成：

• 起始行（start line）：描述请求或响应的基本信息；
• 头部字段集合（header）：使用 key-value 形式更详细地说明报文；
• 空行：也就是“CRLF”，十六进制的“0D0A”。
• 消息正文（entity/body）：实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据。

HTTP 协议规定报文必须有 header，但可以没有 body，而且在 header 之后必须要有一个“空行”。

上面的起始行与头部字段又经常和称为**“请求头”或“响应头“**。其中：

• 请求头由“请求行 + 头部字段”构成，响应头由“状态行 + 头部字段”构成。
• 请求行有三部分：请求方法，请求目标和版本号；状态行也有三部分：版本号，状态码和原因字符串；

// 请求行:“GET”是请求方法，“/”是请求目标，“HTTP/1.1”是版本
// 常见请求方法：GET, POST, PUT, DELETE, OPTIONS, HEAD
GET / HTTP/1.1

// 响应行
HTTP/1.1 200 OK

• 请求行或状态行再加上头部字段集合就构成了 HTTP 报文里完整的请求头或响应头，如下图所示。其中，头部字段是 key-value 的形式，用“:”分隔，不区分大小写，顺序任意，除了规定的标准头，也可以任意添加自定义字段，实现功能扩展；
• HTTP/1.1 里唯一要求必须提供的头字段是 Host，它必须出现在请求头里，标记虚拟主机名。

HTTP 协议规定了非常多的头部字段，实现各种各样的功能，但基本上可以分为四大类：

• 通用字段：在请求头和响应头里都可以出现；
  • Date：通常出现在响应头里，表示 HTTP 报文创建的时间，客户端可以使用这个时间再搭配其他字段决定缓存策略。
• 请求字段：仅能出现在请求头里，进一步说明请求信息或者额外的附加条件；
  • Host：只能出现在请求头里，标记虚拟主机名。
  • User-Agent：只出现在请求头里。它使用一个字符串来描述发起 HTTP 请求的客户端，服务器可以依据它来返回最合适此浏览器显示的页面。
• 响应字段：仅能出现在响应头里，补充说明响应报文的信息；
  • Server：服务器部分信息，例如Apache/Nginx。最好不暴露，容易被攻击。
• 实体字段：它实际上属于通用字段，但专门描述 body 的额外信息。
  • Content-Length：表示报文里 body 的长度，也就是请求头或响应头空行后面数据的长度。

详细可参考：https://time.geekbang.org/column/article/100513

HTTP有哪些状态码？

状态码分类

• 1xx：表示目前是协议的中间状态，还需要后续请求
• 2xx：表示请求成功
• 3xx：表示重定向状态，要完成请求必须进行进一步处理
• 4xx：表示客户端请求报文错误
• 5xx：表示服务端处理请求错误

常用状态码

• 101：切换请求协议，从 HTTP 切换到 WebSocket
• 200 OK： 请求成功，有响应体
• 204：等同于请求执行成功，但是没有数据，浏览器不用刷新页面，也不用导向新的页面
• 301 Moved Permanently：永久重定向，会缓存，使用域名跳转
• 302 Found ： 临时重定向，不会缓存
• 304 ：协商缓存命中，对比缓存使用的状态码
• 400 Bad Request：客户端请求有语法错误，不能被服务器所理解
• 401 Unauthorized ：请求未经授权，这个状态代码必须和 WWW-Authenticate 报头域一起使用
• 403 Forbidden：客户端错误，服务器拒绝授权访问
• 404 Not Found：客户端错误，服务器端无法找到所请求的资源 eg：输入了错误的 URL
• 422：表示服务器理解请求实体的内容类型，并且请求实体的语法是正确的，但是服务器无法处理所包含的指令。
• 500 Internal Server Error：服务器发生不可预期的错误
• 501 Not Implemented：服务器错误响应码表示请求的方法不被服务器支持，因此无法被处理。服务器必须支持的方法（即不会返回这个状态码的方法）只有 GET和 HEAD。
• 502 Bad Gateway：一种HTTP协议的服务器端错误状态代码，它表示作为网关或代理角色的服务器，从上游服务器（如tomcat、php-fpm）中接收到的响应是无效的。
• 503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常（服务器宕机）。

HTTP与HTTPS有什么区别？

端口 ：HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。

安全性和资源消耗： HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上（HTTP + 加密 + 认证 + 完整性保护 = HTTPS ）。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。

• 对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；
• 非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。

HTTP 1.0和HTTP 1.1的主要区别是什么?

HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在：

1. 长连接 : 在HTTP/1.0中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接。HTTP 是基于TCP/IP协议的,每一次建立或者断开连接都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大。因此最好能维持一个长连接，可以用个长连接来发多个请求。HTTP 1.1起，默认使用长连接 ,默认开启Connection： keep-alive。 HTTP/1.1的持续连接有非流水线方式和流水线方式 。流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前一个响应后才能发送下一个请求。
2. 错误状态响应码 :在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
3. 缓存处理 :在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
4. 带宽优化及网络连接的使用 :HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

HTTP是不保存状态的协议，如何保存用户状态?

HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个Session）。

在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库redis保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。

Cookie 被禁用怎么办?

最常用的就是利用 URL 重写把 Session ID 直接附加在URL路径的后面。

HTTP长连接，短连接区别？

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

HTTP 缓存机制了解吗？

HTTP缓存机制其实是提高访问速度和解决信息不同步的一种机制。这种信息不同步在生活中很常见，很多解决思路我们已经司空见惯，带着这种思维，我们可以很好的理解HTTP缓存机制。HTTP缓存机制要点如下：

HTTP缓存机制分为强制缓存和协商缓存两类。

• 强制缓存的意思就是不要问了(不发起请求)，直接用缓存吧。强制缓存常见技术有Expires和Cache-Control。

  • Expires的值是一个时间，表示这个时间前缓存都有效，都不需要发起请求。
  • Cache-Control有很多属性值，常用属性max-age设置了缓存有效的时间长度，单位为秒，这个时间没到，都不用发起请求。
  • immutable也是Cache-Control的一个属性，表示这个资源这辈子都不用再请求了，但是他兼容性不好，Cache-Control其他属性可以参考MDN的文档。
  • Cache-Control的max-age优先级比Expires高。

• 协商缓存常见技术有ETag和Last-Modified。

  • ETag其实就是给资源算一个hash值或者版本号，对应的常用request header为If-None-Match。
  • Last-Modified其实就是加上资源修改的时间，对应的常用request header为If-Modified-Since，精度为秒。
  • ETag每次修改都会改变，而Last-Modified的精度只到秒，所以ETag更准确，优先级更高，但是需要计算，所以服务端开销更大。

强制缓存和协商缓存都存在的情况下，先判断强制缓存是否生效，如果生效，不用发起请求，直接用缓存。如果强制缓存不生效再发起请求判断协商缓存。

详细可参考：https://segmentfault.com/a/1190000038562294、https://www.cnblogs.com/chenqf/p/6386163.html

说一说POST与GET有哪些区别？

GET 用于获取资源，而 POST 用于传输实体主体。GET 和 POST 的请求都能使用额外的参数，但是 GET 的参数是以查询字符串出现在 URL 中，而 POST 的参数存储在实体主体中。不能因为 POST 参数存储在实体主体中就认为它的安全性更高，因为照样可以通过一些抓包工具（Fiddler）查看。

• 请求参数：GET请求参数是通过URL传递的，多个参数以&连接，POST请求放在request body中。
• 请求缓存：GET请求会被缓存，而POST请求不会，除非手动设置。
  • 请求报文的 HTTP 方法本身是可缓存的，包括 GET 和 HEAD，但是 PUT 和 DELETE 不可缓存，POST 在多数情况下不可缓存的。
  • 响应报文的状态码是可缓存的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501。响应报文的 Cache-Control 首部字段没有指定不进行缓存。
• 收藏为书签：GET请求支持，POST请求不支持。
• 安全性：POST比GET安全，GET请求在浏览器回退时是无害的，而POST会再次请求。
  • 安全的方法除了 GET 之外还有：HEAD、OPTIONS；不安全的方法除了 POST 之外还有 PUT、DELETE。
• 历史记录：GET请求参数会被完整保留在浏览历史记录里，而POST中的参数不会被保留。
• 编码方式：GET请求只能进行URL编码，而POST支持多种编码方式。
• 对参数的数据类型：GET只接受ASCII字符，而POST没有限制支持标准字符集。
• 幂等性：正常来说，GET/HEAD/PUT/ DELETE等方法都是幂等的，而 POST 方法不是。

其他问题

Cookie的作用是什么?和Session有什么区别？

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。

Cookie 一般用来保存用户信息 比如①我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；②一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；③登录一次网站后访问网站其他页面不需要重新登录。Session 的主要作用就是通过服务端记录用户的状态。 典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。

Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。

URI和URL的区别是什么?

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

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

简述一下 ping 的原理？

ping 是基于 ICMP 协议工作的。ICMP全称Internet Control Message Protocol，就是互联网控制报文协议。这里面的关键词是“控制”，那具体是怎么控制的呢？ 网络包在异常负责的网络环境中传输时，会遇到各种问题，当遇到问题时，要传出消息，报告情况，这样才能调整传输策略。

ICMP 报文是封装在 IP 包里面的。因为传输指令的时候，肯定需要源地址和目标地址。如下图：

常用的ping 就是查询报文，是一种主动请求，并且获得主动应答的 ICMP 协议。

IP 地址与 MAC 地址的区别？

可查看MAC地址和IP地址的区别与联系（计算机网络篇）一文

我们可以归纳出IP地址和MAC地址相同点是它们都唯一，不同的特点主要有：

1. 对于网络上的某一设备，如一台计算机或一台路由器，其IP地址可变（但必须唯一），而MAC地址不可变。我们可以根据需要给一台主机指定任意的IP地址，如我们可以给局域网上的某台计算机分配IP地址为192.168.0.112 ，也可以将它改成192.168.0.200。而任一网络设备（如网卡，路由器）一旦生产出来以后，其MAC地址永远唯一且不能由用户改变。
　　2. 长度不同。IP地址为32位，MAC地址为48位。
　　3. 分配依据不同。IP地址的分配是基于网络拓朴，MAC地址的分配是基于制造商。
　　4. 寻址协议层不同。IP地址应用于OSI第三层，即网络层，而MAC地址应用在OSI第二层，即数据链路层。 数据链路层协议可以使数据从一个节点传递到相同链路的另一个节点上（通过MAC地址），而网络层协议使数据可以从一个网络传递到另一个网络上（ARP根据目的IP地址，找到中间节点的MAC地址，通过中间节点传送，从而最终到达目的网络）。

请求转发和重定向的区别？

转发（Forward）：服务器直接访问目标资源地址的URL，读取并发送目标URL返回的内容到浏览器，这个过程浏览器是不知道，浏览器的地址栏还是原来的地址。 转发的路径必须是同一个web容器下的URL，其不能转向到其他的web路径上去，中间传递的也是自己的容器内的request，故转发页面和转发到的页面可以共享request里面的数据。

重定向（Redirect）：是服务器根据处理逻辑，返回一个302状态码和新请求地址，告诉浏览器重新去请求这个URL，这时浏览器的地址栏就会变成新的URL。也就是收重定向是发生在客户端的跳转，其实是两次请求，所以这个新地址可以重定向到新的的URL，并且两次请求的request是不共享的。

形象的解释，你去拖人办事：

• 重定向：你先去了A局，A局的人说：“这个事情不归我们管，去B局”，然后，你就从A退了出来，自己乘车去了B局。

• 转发：你先去了A局，A局看了以后，知道这个事情其实应该B局来管，但是他没有把你退回来，而是让你坐一会儿，自己到后面办公室联系了B的人，让他们办好后，送了过来。

总结下来，转发是服务器行为，重定向是客户端行为。区别主要在于：

• 请求转发只能将请求转发给同一个WEB应用中的组件，而重定向还可以重新定向到同一站点不同应用程序中的资源，甚至可以定向到一绝对的URL。
• 重定向可以看见目标页面的URL，转发只能看见第一次访问的页面URL，以后的工作都是有服务器来做的。
• 请求转发调用者和被调用者之间共享相同的request对象和response对象，重定向调用者和被调用者属于两个独立访问请求和响应过程。
• 重定向跳转后必须加上return，要不然页面虽然跳转了，但是还会执行跳转后面的语句，转发是执行了跳转页面，下面的代码就不会在执行了。

重定向常见应用 —— 短连接跳转

• 例如给用户发送短信的时候，发送一个链接，当用户点击链接的时候，能够打开app，同时跳转到app的某一个页面。

DNS 的解析过程？

主机向本地域名服务器的查询一般都是采用递归查询。所谓递归查询就是：如果主机所询问的本地域名服务器不知道被查询的域名的 IP 地址，那么本地域名服务器就以 DNS 客户的身份，向根域名服务器继续发出查询请求报文(即替主机继续查询)，而不是让主机自己进行下一步查询。因此，递归查询返回的查询结果或者是所要查询的 IP 地址，或者是报错，表示无法查询到所需的 IP 地址。

本地域名服务器向根域名服务器的查询的迭代查询。迭代查询的特点：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的 IP 地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”。然后让本地服务器进行后续的查询。根域名服务器通常是把自己知道的顶级域名服务器的 IP 地址告诉本地域名服务器，让本地域名服务器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的查询请求后，要么给出所要查询的 IP 地址，要么告诉本地服务器下一步应当向哪一个权限域名服务器进行查询。最后，本地域名服务器得到了所要解析的 IP 地址或报错，然后把这个结果返回给发起查询的主机。

在浏览器中输入 URL 地址到显示主页的过程，整个过程会使用哪些协议

打开一个网页，整个过程会使用哪些协议？具体可以参考下面这篇文章：从输入URL到页面加载发生了什么？

图解（图片来源：《图解HTTP》）：

总体来说分为以下几个过程:

1. DNS解析：通过访问的域名找出其 IP 地址，递归搜索；
   • 域名到IP地址的转换，递归查询DNS服务器，本地域名服务器-根域名服务器-顶级域名服务器（. -> .com -> google.com. -> www.google.com.）
   • DNS缓存-浏览器缓存，系统缓存，路由器缓存，IPS服务器缓存，根域名服务器缓存，顶级域名服务器缓存，主域名服务器缓存；
   • DNS负载均衡；
2. TCP连接：浏览器获得域名对应的 IP 地址以后，浏览器向服务器请求建立连接，发起三次握手；
3. 发送 HTTP 请求：TCP 连接建立起来后，浏览器向服务器发送 HTTP 请求；
4. 服务器处理请求并返回 HTTP 报文：服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
5. 浏览器解析渲染页面：浏览器解析HTML文件构建DOM树并渲染视图，若遇到对 JS 文件、CSS文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。
6. 关闭连接：TCP四次挥手关闭连接。

如何缓解DDoS 攻击？

DDoS 的前身是 DoS（Denail of Service），即拒绝服务攻击，指利用大量的合理请求，来占用过多的目标资源，从而使目标服务无法响应正常请求。

DDoS（Distributed Denial of Service） 则是在 DoS 的基础上，采用了分布式架构，利用多台主机同时攻击目标主机。这样，即使目标服务部署了网络防御设备，面对大量网络请求时，还是无力应对。

从攻击的原理上来看，DDoS 可以分为下面几种类型。

• 第一种，耗尽带宽。无论是服务器还是路由器、交换机等网络设备，带宽都有固定的上限。带宽耗尽后，就会发生网络拥堵，从而无法传输其他正常的网络报文。
• 第二种，耗尽操作系统的资源。网络服务的正常运行，都需要一定的系统资源，像是 CPU、内存等物理资源，以及连接表等软件资源。一旦资源耗尽，系统就不能处理其他正常的网络连接。
• 第三种，消耗应用程序的运行资源。应用程序的运行，通常还需要跟其他的资源或系统交互。如果应用程序一直忙于处理无效请求，也会导致正常请求的处理变慢，甚至得不到响应。

比如，构造大量不同的域名来攻击 DNS 服务器，就会导致 DNS 服务器不停执行迭代查询，并更新缓存。这会极大地消耗 DNS 服务器的资源，使 DNS 的响应变慢。

实际上，SYN Flood（泛洪攻击）正是互联网中最常见的 DDoS 攻击方式。上面TCP三次握手处已经介绍过它的原理：

• 即客户端构造大量的 SYN 包，请求建立 TCP 连接；
• 而服务器收到包后，会向源 IP 发送 SYN+ACK 报文，并等待三次握手的最后一次 ACK 报文，直到超时。

这种等待状态的 TCP 连接，通常也称为半开连接。由于连接表的大小有限，大量的半开连接就会导致连接表迅速占满，从而无法建立新的 TCP 连接。

那么如何缓解DDOS攻击呢？

• 设置高性能设备

  要保证网络设备不能成为瓶颈，因此选择路由器、交换机、硬件防火墙等设备时要尽量选用知名度高、口碑好的产品。并且，假如和网络提供商有特殊关系或协议的话就更好了，当大量攻击发生时请他们在网络接点处做一下流量限制来对抗某些种类的 DDoS 攻击是非常有效的。

• 带宽得保证

  网络带宽直接决定了能抗受攻击的能力，假若仅仅只有 10M 带宽的话，无论采取什么措施都很难对抗现在的 SYN Flood 攻击。所以，最好选择 100M 的共享带宽，挂在 1000M 的主干上。

• 不要忘记升级

  在有网络带宽保证的前提下，请尽量提升硬件配置，要有效对抗每秒 10 万个 SYN 攻击包。而且最好可以进行优化资源使用，提高 web server 的负载能力。

• 异常流量的清洗

  通过 DDoS 硬件防火墙对异常流量的清洗过滤，通过数据包的规则过滤、数据流指纹检测过滤、及数据包内容定制过滤等顶尖技术能准确判断外来访问流量是否正常，进一步将异常流量禁止过滤。

• 考虑把网站做成静态页面

  将网站尽可能做成静态页面，不仅能大大提高抗攻击能力，而且还给黑客入侵带来不少麻烦，最好在需要调用数据库的脚本中，拒绝使用代理的访问，经验表明，使用代理访问你网站的 80% 属于恶意行为。

• 分布式集群防御

  这种方法的特点是在每个节点服务器配置多个 IP 地址，并且每个节点能承受不低于 10G 的 DDoS 攻击，如一个节点受攻击无法提供服务，系统将会根据优先级设置自动切换另一个节点，并将攻击者的数据包全部返回发送点，使攻击源成为瘫痪状态，从更为深度的安全防护角度去影响企业的安全执行决策。

什么是XSS攻击？如何防范？

XSS是一种经常出现在web应用中的计算机安全漏洞，与SQL注入一起成为web中最主流的攻击方式。

XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些脚本代码嵌入到web页面中去，使别的用户访问都会执行相应的嵌入代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

XSS攻击的危害

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

原因解析

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

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

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

XSS 攻击分类

• 反射性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>！

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

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

XSS攻击向量(一般指XSS攻击代码)存储在网站数据库，当一个页面被用户打开的时候执行。也就是说，每当用户使用浏览器打开指定页面时，脚本便执行。

与非持久性XSS攻击相比，持久性XSS攻击危害性更大。从名字就可以了解到，持久性XSS攻击就是将攻击代码存入数据库中，然后客户端打开时就执行这些攻击代码。

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

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

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

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

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

修复漏洞方针

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

• 将重要的Cookie标记为HttpOnly，这样的话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代码拼接、或者此表单直接允许使用等等），然后区别处理！

什么是数字签名与数字证书？

数字签名

为了避免数据在传输过程中被替换，比如黑客修改了你的报文内容，但是你并不知道，所以我们让发送端做一个数字签名，把数据的摘要消息进行一个加密，比如 MD5，得到一个签名，和数据一起发送。然后接收端把数据摘要进行 MD5 加密，如果和签名一样，则说明数据确实是真的。

数字证书

对称加密中，双方使用公钥进行解密。虽然数字签名可以保证数据不被替换，但是数据是由公钥加密的，如果公钥也被替换，则仍然可以伪造数据，因为用户不知道对方提供的公钥其实是假的。所以为了保证发送方的公钥是真的，CA 证书机构会负责颁发一个证书，里面的公钥保证是真的，用户请求服务器时，服务器将证书发给用户，这个证书是经由系统内置证书的备案的。