【面试招聘】计算机网络专场（一）_名词解释交流环境的嗅探

关键词：[计网] [TCP/IP] [HTTP]

三次握手和四次挥手

三次握手
  所谓的三次握手即TCP连接的建立。这个连接必须是一方主动打开，另一方被动打开的。以下为客户端主动发起连接的图解：

  握手之前主动打开连接的客户端结束CLOSED阶段，被动打开的服务器端也结束CLOSED阶段，并进入LISTEN阶段。随后开始“三次握手”：

• 第一次握手：首先客户端向服务器端发送一段TCP报文，其中：
  标记位为SYN，表示“请求建立新连接”;
  序号为Seq=X；初始化序号ISN是动态随机的；
  随后客户端进入SYN-SENT阶段。
• 第二次握手：服务器端接收到来自客户端的TCP报文之后，结束LISTEN阶段。并返回一段TCP报文，其中：
  标志位为SYN和ACK，表示“确认客户端的报文Seq序号有效，服务器能正常接收客户端发送的数据，并同意创建新连接”（即告诉客户端，服务器收到了你的数据）；
  序号为Seq=y；
  确认号为Ack=x+1，表示收到客户端的序号Seq并将其值加1作为自己确认号Ack的值；随后服务器端进入SYN-RCVD阶段。
• 第三次握手：客户端接收到来自服务器端的确认收到数据的TCP报文之后，明确了从客户端到服务器的数据传输是正常的，结束SYN-SENT阶段。并返回最后一段TCP报文。其中：
  标志位为ACK，表示“确认收到服务器端同意连接的信号”（即告诉服务器，我知道你收到我发的数据了）；
  序号为Seq=x+1，表示收到服务器端的确认号Ack，并将其值作为自己的序号值；
  确认号为Ack=y+1，表示收到服务器端序号Seq，并将其值加1作为自己的确认号Ack的值；
  随后客户端进入ESTABLISHED阶段。
  服务器收到来自客户端的“确认收到服务器数据”的TCP报文之后，明确了从服务器到客户端的数据传输是正常的。结束SYN-SENT阶段，进入ESTABLISHED阶段。

  在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性。一旦出现某一方发出的TCP报文丢失，便无法继续"握手"，以此确保了"三次握手"的顺利完成。

Q：为什么进行三次握手？
  为了防止服务器端开启一些无用的连接增加服务器开销以及防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

  由于网络传输是有延时的(要通过网络光纤和各种中间代理服务器)，在传输的过程中，比如客户端发起了SYN=1创建连接的请求(第一次握手)。如果服务器端就直接创建了这个连接并返回包含SYN、ACK和Seq等内容的数据包给客户端，这个数据包因为网络传输的原因丢失了，丢失之后客户端就一直没有接收到服务器返回的数据包。

  客户端可能设置了一个超时时间，时间到了就关闭了连接创建的请求。再重新发出创建连接的请求，而服务器端是不知道的，如果没有第三次握手告诉服务器端客户端收的到服务器端传输的数据的话，服务器端是不知道客户端有没有接收到服务器端返回的信息的。这个过程可理解为：

  这样没有给服务器端一个创建还是关闭连接端口的请求，服务器端的端口就一直开着，等到客户端因超时重新发出请求时，服务器就会重新开启一个端口连接。那么服务器端上没有接收到请求数据的上一个端口就一直开着，长此以往，这样的端口多了，就会造成服务器端开销的严重浪费。

  还有一种情况是已经失效的客户端发出的请求信息，由于某种原因传输到了服务器端，服务器端以为是客户端发出的有效请求，接收后产生错误。

  所以我们需要“第三次握手”来确认这个过程，让客户端和服务器端能够及时地察觉到因为网络等一些问题导致的连接创建失败，这样服务器端的端口就可以关闭了不用一直等待，即可以减少服务器开销和接收到失效请求发生的错误。

四次挥手
那TCP 的四次挥手，是为了保证通信双方都关闭了连接，具体过程如下：

1）客户端 A 发送一个 FIN，用来关闭客户 A 到服务器 B 的数据传送；
2）服务器 B 收到这个 FIN，它发回一个 ACK，确认序号为收到的序号加 1。和 SYN 一样，一个 FIN 将占用一个序号；
3）服务器 B 关闭与客户端 A 的连接，发送一个 FIN 给客户端 A；
4）客户端 A 发回 ACK 报文确认，并将确认序号设置为收到序号加 1。

Q：为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？

  这是因为服务端的 LISTEN 状态下的 SOCKET 当收到 SYN 报文的建连请求后，它可以把 ACK 和 SYN（ACK 起应答作用，而 SYN 起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的 FIN 报文通知时，它仅仅表示对方没有数据发送给你了，但是你还可以给对方发送数据，或者还有一些数据在传给对方的途中，所以你不能立马关闭连接，也即你可能还需要把在传输途中的数据给对方之后，又或者，你还有一些数据需要传输给对方后，（再关闭连接）再发送FIN 报文给对方来表示你同意现在可以关闭连接了，所以它这里的 ACK 报文和 FIN 报文多数情况下都是分开发送的。

Q：为什么客户端在TIME_WAIT 状态还需要等 2MSL后才能返回到 CLOSED 状态？

  为的是确认服务器端是否收到客户端发出的ACK确认报文；当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器。MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长（一个来回的时间）。服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；

初始化序列号 ISN(s)
ISN代表什么？意义何在？

  ISN，发送方的字节数据编号的原点，让对方生成一个合法的接收窗口。

ISN是固定不变的吗？

  动态随机。

ISN为何要动态随机？

  增加安全性，为了避免被第三方猜测到，从而被第三方伪造的RST报文Reset。

刚才你提到第三方可以伪造RST报文，需要满足什么条件才能得逞？
  需要sequence number 位于对方的合法接收窗口内。 而由于ISN是动态随机的，猜出对方合法接收窗口难度加大。如果ISN = 0，那就很容易猜出来了；

三次握手的第一次可以携带数据吗？为何？
  不可以，三次握手还没有完成；

对方难道不可以将数据缓存下来，等握手成功再提交给应用程序？
  这样会放大SYN FLOOD攻击。如果攻击者伪造了成千上万的握手报文，携带了1K+ 字节的数据，而接收方会开辟大量的缓存来容纳这些巨大数据，内存会很容易耗尽，从而拒绝服务。

第三次可以携带数据吗？为何？

  可以；第三次本就是向服务器回复已收到服务器的请求连接信息，自然可以携带信息；服务器会在三次握手完成后，处理你发送的数据；

能够发出第三次握手报文的主机，肯定接收到第二次(服务器)握手报文，对吗？

  因为伪造IP的主机是不会接收到第二次报文的。所以，能够发出第三次握手报文的，应该是合法的用户。尽管服务器侧的状态还没有“established”，接收到第三次握手的瞬间，状态就会切换为“established”，里面携带的数据按照正常流程走就好。

看到有人说，只看到过TCP状态位为 ’FIN +ACK’，但从来没有看过状态位只有 ‘FIN’，你应该怎样给他解释？
  RFC793明确规定，除了第一个握手报文SYN除外，其它所有报文必须将ACK = 1。

RFC规定的背后肯定有合理性的一面，能否深究一下原因？
  TCP作为一个可靠传输协议，其可靠性就是依赖于收到对方的数据，ACK对方，这样对方就可以释放缓存的数据（因为一但消息丢失，就要进行重发，重发缓冲区里面的数据），因为对方确信数据已经被接收到了。但TCP报文是在IP网络上传输，丢包是家常便饭，接收方要抓住一切的机会，把消息告诉发送方。最方便的方式就是，任何我方发送的TCP报文，都要捎带着ACK状态位。

ACK状态位单独能承担这个消息传递的任务吗？
  不能！需要有 Acknowledge Number配合才行。如果我方发出的Acknowledge Number == 10001，那意味着序列号10000及之前的字节已经成功接收。如果对方占据字节序列号10000是应用层数据，那么就是确认应用层数据。如果对方占据字节序列号10000是’FIN’状态位，那么就是确认接收到对方的’FIN’。

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

Q：两次握手不行吗？为什么TCP客户端最后还要发送一次确认呢？

  主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。经典场景：客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了；

  由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

Q：为什么三次握手，返回时，ack 值是 seq 加 1（ack = x+1）

  假设对方接收到数据，比如sequence number = 1000，TCP Payload = 1000，数据第一个字节编号为1000，最后一个为1999，回应一个确认报文，确认号为2000，意味着编号2000前的字节接收完成，准备接收编号为2000及更多的数据；确认收到的序列，并且告诉发送端下一次发送的序列号从哪里开始（便于接收方对数据排序，便于选择重传）

Q：SYN洪泛攻击(SYN Flood，半开放攻击)，怎么解决？

什么是SYN洪范泛攻击？
  SYN Flood洪泛攻击发生在osl第四层，这种方式利用TCP协议的特性，就是三次握手。攻击者发送TCP SYN，SYN是TCP三次握手中的第一个数据包，而当服务器返回ACK后，该攻击者就不对其进行再确认，那这个TCP连接就处于挂起状态，也就是所谓的半连接状态，服务器收不到再确认的话，还会重复发送ACK给攻击者。这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接，由于每一个都没法完成三次握手，所以在服务器上，这些TCP连接会因为挂起状态而消耗cPU和内存，最后服务器可能死机，就无法为正常用户提供服务了；

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

怎么解决？

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

SYN cookies技术：
  当服务器接受到 SYN 报文段时，不直接为该 TCP 分配资源，而只是打开一个半开的套接字。接着会使用 SYN 报文段的源 Id，目的 Id，端口号以及只有服务器自己知道的一个秘密函数生成一个 cookie，并把 cookie 作为序列号响应给客户端。
  如果客户端是正常建立连接，将会返回一个确认字段为 cookie + 1 的报文段。接下来服务器会根据确认报文的源 Id，目的 Id，端口号以及秘密函数计算出一个结果，如果结果的值 + 1 等于确认字段的值，则证明是刚刚请求连接的客户端，这时候才为该 TCP 分配资源

Q：TCP三次握手中，最后一次回复丢失，会发生什么？

  如果最后一次ACK在网络中丢失，那么Server端（服务端）该TCP连接的状态仍为SYN_RECV，并且根据 TCP的超时重传机制依次等待3秒、6秒、12秒后重新发送 SYN+ACK 包，以便 Client（客户端）重新发送ACK包
如果重发指定次数后，仍然未收到ACK应答，那么一段时间后，Server（服务端）自动关闭这个连接
但是Client（客户端）认为这个连接已经建立，如果Client（客户端）端向Server（服务端）发送数据，Server端（服务端）将以RST包（Reset，标示复位，用于异常的关闭连接）响应，此时，客户端知道第三次握手失败；

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

  建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
  关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了,所以服务器可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接。因此，服务器ACK和FIN一般都会分开发送，从而导致多了一次。

Q：为什么TCP挥手每两次中间有一个 FIN-WAIT2等待时间？

  主动关闭的一端调用完close以后（即发FIN给被动关闭的一端， 并且收到其对FIN的确认ACK）则进入FIN_WAIT_2状态。如果这个时候因为网络突然断掉、被动关闭的一段宕机等原因，导致主动关闭的一端不能收到被动关闭的一端发来的FIN（防止对端不发送关闭连接的FIN包给本端），这个时候就需要FIN_WAIT_2定时器， 如果在该定时器超时的时候，还是没收到被动关闭一端发来的FIN，那么直接释放这个链接，进入CLOSE状态；

Q：为什么客户端最后还要等待2MSL？为什么还有个TIME-WAIT的时间等待？

  保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，服务器已经发送了FIN+ACK报文，请求断开，客户端却没有回应，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
  防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，这样新的连接中不会出现旧连接的请求报文。
  2MSL，最大报文生存时间，一个MSL 30 秒，2MSL = 60s

Q：客户端 TIME-WAIT 状态过多会产生什么后果？怎样处理？

  作为服务器，短时间内关闭了大量的Client连接，就会造成服务器上出现大量的TIME_WAIT连接，占据大量的tuple /tApl/ ，严重消耗着服务器的资源，此时部分客户端就会显示连接不上；作为客户端，短时间内大量的短连接，会大量消耗的Client机器的端口，毕竟端口只有65535个，端口被耗尽了，后续就无法在发起新的连接了；
  在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上
  高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少了；短连接表示“业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间”的连接

解决方法：

• 用负载均衡来抗这些高并发的短请求；
• 服务器可以设置 SO_REUSEADDR 套接字选项来避免 TIME_WAIT状态，TIME_WAIT 状态可以通过优化服务器参数得到解决，因为发生TIME_WAIT的情况是服务器自己可控的，要么就是对方连接的异常，要么就是自己没有迅速回收资源，总之不是由于自己程序错误导致的；
• 强制关闭，发送 RST 包越过TIMEWAIT状态，直接进入CLOSED状态；

Q：服务器出现了大量 CLOSE_WAIT 状态如何解决？

  大量 CLOSE_WAIT 表示程序出现了问题，对方的 socket 已经关闭连接，而我方忙于读或写没有及时关闭连接，需要检查代码，特别是释放资源的代码，或者是处理请求的线程配置。

Q：服务端会有一个TIME_WAIT状态吗？如果是服务端主动断开连接呢？

  发起连接的主动方基本都是客户端，但是断开连接的主动方服务器和客户端都可以充当，也就是说，只要是主动断开连接的，就会有 TIME_WAIT状态；四次挥手是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发；由于TCP连接时全双工的，因此，每个方向的数据传输通道都必须要单独进行关闭。

TIME_CLOSE 和 TIME_WAIT 的状态和意义
TIME_WAIT

  TIME_WAIT 是主动关闭连接时形成的，等待2MSL时间，约4分钟。主要是防止最后一个ACK丢失。 由于TIME_WAIT 的时间会非常长，因此server端应尽量减少主动关闭连接；

CLOSE_WAIT
  CLOSE_WAIT是被动关闭连接是形成的。根据TCP状态机，服务器端收到客户端发送的FIN，则按照TCP实现发送ACK，因此进入CLOSE_WAIT状态。但如果服务器端不执行close()，就不能由CLOSE_WAIT迁移到LAST_ACK，则系统中会存在很多CLOSE_WAIT状态的连接。此时，可能是系统忙于处理读、写操作，而未将已收到FIN的连接，进行close。此时，recv/read已收到FIN的连接socket，会返回0。

为什么需要 TIME_WAIT 状态？
  假设最终的ACK丢失，server将重发FIN，client 必须维护TCP状态信息以便可以重发最终的ACK，否则会发送RST，结果server认为发生错误。TCP实现必须可靠地终止连接的两个方向(全双工关闭)，client必须进入 TIME_WAIT 状态，因为client可能面 临重发最终ACK的情形；

TCP 如何保证可靠传输

TCP协议保证数据传输可靠性的方式主要有：

1. 校验和
  计算方式：在数据传输的过程中，将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃，补在后面，最后取反，得到校验和。
发送方：在发送数据之前计算检验和，并进行校验和的填充。
接收方：收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方的进行比对。

  注意：如果接收方比对校验和与发送方不一致，那么数据一定传输有误。但是如果接收方比对校验和与发送方一致，数据不一定传输成功。

2. 确认应答和序列号
序列号：TCP传输时将每个字节的数据都进行了编号，这就是序列号。
确认应答：TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。

确认应答=序列号结尾+1，即告诉它下一次发送数据要从这里发起；

  序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。这也是TCP传输可靠性的保证之一；

3. 超时重传
  在进行TCP传输时，由于确认应答与序列号机制，也就是说发送方发送一部分数据后，都会等待接收方发送的ACK报文，并解析ACK报文，判断数据是否传输成功。如果发送方发送完数据后，迟迟没有等到接收方的ACK报文，这该怎么办呢？而没有收到ACK报文的原因可能是什么呢？

  首先，发送方没有介绍到响应的ACK报文原因可能有两点：

1. 数据在传输过程中由于网络原因等直接全体丢包，接收方根本没有接收到；
2. 接收方接收到了响应的数据，但是发送的ACK报文响应却由于网络原因丢包了；

  TCP在解决这个问题的时候引入了一个新的机制，叫做超时重传机制。简单理解就是发送方在发送完数据后等待一个时间，时间到达没有接收到ACK报文，那么对刚才发送的数据进行重新发送。如果是刚才第一个原因，接收方收到二次重发的数据后，便进行ACK应答。如果是第二个原因，接收方发现接收的数据已存在（判断存在的根据就是序列号，所以上面说序列号还有去除重复数据的作用），那么直接丢弃，仍旧发送ACK应答。
  那么发送方发送完毕后等待的时间是多少呢？如果这个等待的时间过长，那么会影响TCP传输的整体效率，如果等待时间过短，又会导致频繁的发送重复的包。如何权衡？
  由于TCP传输时保证能够在任何环境下都有一个高性能的通信，因此这个最大超时时间（也就是等待的时间）是动态计算的。
  在Linux中（BSD Unix和Windows下也是这样）超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。重发一次后，仍未响应，那么等待2500ms的时间后，再次重传。等待4500ms的时间继续重传。以一个指数的形式增长。累计到一定的重传次数，TCP就认为网络或者对端出现异常，强制关闭连接。

4. 连接管理
  接管理就是三次握手与四次挥手的过程；保证可靠的连接，是保证可靠性的前提。
5. 流量控制
  收端在接收到数据后，对其进行处理。如果发送端的发送速度太快，导致接收端的结束缓冲区很快的填充满了。此时如果发送端仍旧发送数据，那么接下来发送的数据都会丢包，继而导致丢包的一系列连锁反应，超时重传呀什么的。而TCP根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制；

  在TCP协议的报头信息当中，有一个16位字段的窗口大小。在介绍这个窗口大小时我们知道，窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小。这个数字越大，证明接收端接收缓冲区的剩余空间越大，网络的吞吐量越大。接收端会在确认应答发送ACK报文时，将自己的即时窗口大小填入，并跟随ACK报文一起发送过去。而发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。如果接收到窗口大小的值为0，那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段，让接收端把窗口大小告诉发送端。

6. 拥塞控制
  TCP传输的过程中，发送端开始发送数据的时候，如果刚开始就发送大量的数据，那么就可能造成一些问题。网络可能在开始的时候就很拥堵，如果给网络中在扔出大量数据，那么这个拥堵就会加剧。拥堵的加剧就会产生大量的丢包，就对大量的超时重传，严重影响传输。

TCP的四种拥塞控制算法
1.慢开始
2.拥塞控制
3.快重传
4.快恢复
假定：
1.数据是单方向传送，而另一个方向只传送确认
2.接收方总是有足够大的缓存空间，因而发送发发送窗口的大小由网络的拥塞程度来决定
3.以TCP报文段的个数为讨论问题的单位，而不是以字节为单位

  传输轮次：发送方给接收方发送数据报文段后，接收方给发送方发回相应的确认报文段，一个传输轮次所经历的时间就是往返时间RTT(RTT并非是恒定的数值），使用传输轮次是为了强调，把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个报文段的确认，拥塞窗口cwnd会随着网络拥塞程度以及所使用的拥塞控制算法动态变化。

  在tcp双方建立逻辑链接关系时， 拥塞窗口cwnd的值被设置为1，还需设置慢开始门限ssthresh,在执行慢开始算法时，发送方每收到一个对新报文段的确认时，就把拥塞窗口cwnd的值加一，然后开始下一轮的传输，当拥塞窗口cwnd增长到慢开始门限值时，就使用拥塞避免算法。

慢开始：
  假设当前发送方拥塞窗口cwnd的值为1，而发送窗口swnd等于拥塞窗口cwnd，因此发送方当前只能发送一个数据报文段（拥塞窗口cwnd的值是几，就能发送几个数据报文段），接收方收到该数据报文段后，给发送方回复一个确认报文段，发送方收到该确认报文后，将拥塞窗口的值变为2，发送方此时可以连续发送两个数据报文段，接收方收到该数据报文段后，给发送方一次发回2个确认报文段，发送方收到这两个确认报文后，将拥塞窗口的值加2变为4，发送方此时可连续发送4个报文段，接收方收到4个报文段后，给发送方依次回复4个确认报文，发送方收到确认报文后，将拥塞窗口加4，置为8，发送方此时可以连续发送8个数据报文段，接收方收到该8个数据报文段后，给发送方一次发回8个确认报文段，发送方收到这8个确认报文后，将拥塞窗口的值加8变为16；
  即慢开始阶段的拥塞窗口呈指数增长；

当前的拥塞窗口cwnd的值已经等于慢开始门限值，之后改用拥塞避免算法。

拥塞避免：
  也就是每个传输轮次，拥塞窗口cwnd只能线性加一，而不是像慢开始算法时，每个传输轮次，拥塞窗口cwnd按指数增长。同理，16+1……直至到达24，假设24个报文段在传输过程中丢失4个，接收方只收到20个报文段，给发送方依次回复20个确认报文段，一段时间后，丢失的4个报文段的重传计时器超时了，发送发判断可能出现拥塞，更改cwnd和ssthresh.并重新开始慢开始算法，如图所示：

快速重传：

快恢复：

  拥塞控制是TCP在传输时尽可能快的将数据传输，并且避免拥塞造成的一系列问题。是可靠性的保证，同时也是维护了传输的高效性。

CRC 循环校验的算法

  循环冗余校验（Cyclic Redundancy Check， CRC）是一种根据网络数据包或电脑文件等数据产生简短固定位数校验码的一种散列函数，主要用来检测或校验数据传输或者保存后可能出现的错误。它是利用除法及余数的原理来作错误侦测的。

  在数据传输过程中，无论传输系统的设计再怎么完美，差错总会存在，这种差错可能会导致在链路上传输的一个或者多个帧被破坏（出现比特差错，0变为1，或者1变为0），从而接受方接收到错误的数据。为尽量提高接受方收到数据的正确率，在接收方接收数据之前需要对数据进行差错检测，当且仅当检测的结果为正确时接收方才真正收下数据。检测的方式有多种，常见的有奇偶校验、因特网校验和循环冗余校验等。


  接收到的信息为101101001，生成多项式为G(x)= x³+ x²+1，判断传输是否误码；就拿101101001除以1101，因为之前余数为001，所以这个如果没有差错，必然会整除从而使得余数为0，即没有误码；如果余数不为0，说明存在误码；

如何使用 UDP 实现可靠传输

  UDP不属于连接协议，具有资源消耗少，处理速度快的优点，所以通常音频，视频和普通数据在传送时，使用UDP较多，因为即使丢失少量的包，也不会对接受结果产生较大的影响;

  传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。

  最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理，可靠UDP的简单设计。

1、添加seq/ack机制，确保数据发送到对端
2、添加发送和接收缓冲区，主要是用户超时重传。
3、添加超时重传机制。

  详细说明：送端发送数据时，生成一个随机seq=x，然后每一片按照数据大小分配seq。数据到达接收端后接收端放入缓存，并发送一个ack=x的包，表示对方已经收到了数据。发送端收到了ack包后，删除缓冲区对应的数据。时间到后，定时任务检查是否需要重传数据。

目前有如下开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT。

1、RUDP（Reliable User Datagram Protocol）
  RUDP 提供一组数据服务质量增强机制，如拥塞控制的改进、重发机制及淡化服务器算法等，从而在包丢失和网络拥塞的情况下， RTP 客户机（实时位置）面前呈现的就是一个高质量的 RTP 流。在不干扰协议的实时特性的同时，可靠 UDP 的拥塞控制机制允许 TCP 方式下的流控制行为。

2、RTP（Real Time Protocol）
  RTP为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在 UDP 上运行 RTP 以便使用其多路结点和校验服务；这两种协议都提供了传输层协议的功能。但是 RTP 可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式，那么 RTP 可以使用该组播表传输数据到多个目的地。

  RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于底层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。

3、UDT（UDP-based Data Transfer Protocol）
  基于UDP的数据传输协议（UDP-basedData Transfer Protocol，简称UDT）是一种互联网数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输，而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。

  顾名思义，UDT建于UDP之上，并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。由于UDT完全在UDP上实现，它也可以应用在除了高速数据传输之外的其它应用领域，例如点到点技术（P2P），防火墙穿透，多媒体数据传输等等；

HTTPs 与 HTTP

HTTP连接管理

搭载 HTTP 的 TCP
  HTTP 这个应用层协议是以 TCP 为基础来传输数据的。当你想访问一个资源（资源在网络中就是一个 URL）时，你需要先解析这个资源的 IP 地址和端口号，从而和这个 IP 和端口号所在的服务器建立 TCP 连接，然后 HTTP 客户端发起服务请求（GET）报文，服务器对服务器的请求报文做出响应，等到不需要交换报文时，客户端会关闭连接，下面我用图很好的说明了这个过程；

  上面这幅图很好的说明了 HTTP 从建立连接开始 -> 发起请求报文 -> 关闭连接的全过程，但是上面这个过程还忽略了一个很重要的点，那就是TCP 建立连接的过程。

  由于 HTTP 位于 TCP 的上层，所以 HTTP 的请求 -> 响应过程的时效性（性能）很大程度上取决于底层 TCP 的性能，只有在了解了 TCP 连接的性能之后，才可以更好的理解 HTTP 连接的性能，从而才能够实现高性能的 HTTP 应用程序。

通常把一次完整的请求 -> 相应过程称之为 HTTP 事务。

HTTP 时延损耗

从图中可以看出，主要是有下面这几个因素影响 HTTP 事务的时延：

1. 客户端会根据 URL 确定服务器的 IP 和端口号，这里主要是 DNS 把域名转换为 IP 地址的时延，DNS 会发起 DNS 查询，查询服务器的 IP 地址。
2. 第二个时延是 TCP 建立连接时会由客户端向服务器发送连接请求报文，并等待服务器回送响应报文的时延。每条新的 TCP 连接建立都会有建立时延。
3. 一旦连接建立后，客户端就会向服务器请求数据，这个时延主要是服务器从 TCP 连接中读取请求报文，并对请求进行处理的时延。
4. 服务器会向客户端传输响应报文的时延。
5. 最后一个时延是 TCP 连接关闭的时延。

  试想一个问题，假设一个页面有五个资源（元素），每个资源都需要客户端打开一个 TCP 连接、获取资源、断开连接，而且每个连接都是串行打开的，如下图所示：

  串行的意思就是，这五个连接必须是有先后顺序，不会出现同时有两个以上的连接同时打开的情况。

  上面五个资源就需要打开五条连接，资源少还好说，CPU 能够处理，如果页面资源达到上百或者更多的时候呢？每个资源还需要单独再打开一条连接吗？这样显然会急剧增加 CPU 的处理压力，造成大量的时延，显然是没有必要的。

  串行还有一个缺点就是，有些浏览器在对象加载完毕之前是无法知道对象的尺寸（size）的，并且浏览器需要对象尺寸信息来将他们放在屏幕中合理的位置上，所以在加载了足够多的对象之前，屏幕是不会显示任何内容的，这就会造成，其实对象一直在加载，但是我们以为浏览器卡住了。

所以，怎么优化 HTTP 性能的方式呢？
1. 并行连接
  这是一种最常见的，也是最容易想到的一种连接方式，HTTP 允许客户端打开多条连接，并行执行多个 HTTP 事务，加入并行连接后，整个 HTTP 事务的请求过程是这样的，类似于流水线，我在响应连接1时连接2可以发起请求；

  采用并行连接这种方式会克服单条连接的空载时间和带宽限制，因为每个事务都有连接，因此时延能够重叠起来，会提高页面的加载速度。

  但是并行连接并不一定快，如果带宽不够的情况下，甚至页面响应速度还不如串行连接，因为在并行连接中，每个连接都会去竞争使用有效的带宽，每个对象都会以较慢的速度加载，有可能连接 1 加载了 95% ，连接 2 占用带宽加载了 80%，连接 3 ，连接 4 。。。。。。虽然每个对象都在加载，但是页面上却没有任何响应。

  而且，打开大量连接会消耗很多内存资源，从而出现性能问题，上面讨论的就五个连接，这个还比较少，复杂的 web 页面有可能会有数十甚至数百个内嵌对象，也就是说，客户端可以打开数百个连接，而且有许多的客户端同时发出申请，这样很容易会成为性能瓶颈。

  这样看来，并行连接并不一定"快"，实际上并行连接并没有加快页面的传输速度，并行连接也只是造成了一种假象，这是一切并行的通病。

2. 持久连接
  Web 客户端通常会打开到同一个站点的连接，而且初始化了对某服务器请求的应用程序很可能会在不久的将来对这台服务器发起更多的请求，比如获取更多的图片。这种特性被称为站点局部性(site locality)。

  因此，HTTP 1.1 以及 HTTP1.0 的允许 HTTP 在执行完一次事务之后将连接继续保持在打开状态，这个打开状态其实指的就是 TCP 的打开状态，以便于下一次的 HTTP 事务能够复用这条连接。

在一次 HTTP 事务结束之后仍旧保持打开状态的 TCP 连接被称为持久连接。

  非持久连接会在每个事务结束之后关闭，相对的，持久连接会在每个事务结束之后继续保持打开状态。持久连接会在不同事务之间保持打开状态，直到客户端或者服务器决定将其关闭为止。

  长连接也是有缺点的，如果单一客户端发起请求数量不是很频繁，但是连接的客户端却有很多的话，服务器早晚会有崩溃的时候。

  持久连接一般有两种选型方式，一种是 HTTP 1.0 + keep-alive ；一种是 HTTP 1.1 + persistent。

  HTTP 1.1 之前的版本默认连接都是非持久连接，如果想要在旧版本的 HTTP 上使用持久连接，需要指定 Connection 的值为 Keep-Alive。

  HTTP 1.1 版本都是持久性连接，如果想要断开连接时，需要指定 Connection 的值为 close，这也是我们上面说的两种选型方式的版本因素。

下面是使用了持久连接之后的 HTTP 事务与使用串行 HTTP 事务连接的对比图：

  这张图对比了 HTTP 事务在串行连接上和持久连接的时间损耗图，可以看到，HTTP 持久连接省去了连接打开 - 连接关闭的时间，所以在时间损耗上有所缩减。

  在持久性连接中，还有一个非常有意思的地方，就是 Connection 选项，Connection 是一个通用选项，也就是客户端和服务端都具有的一个标头，下面是一个具有持久性连接的客户端和服务端的请求-响应图

  从这张图可以看出，持久连接主要使用的就是 Connection 标头，这也就意味着，Connection 就是持久性连接的实现方式。

Connection 标头
Connection 标头具有两种作用

• 和 Upgrade 一起使用进行协议升级
  也就是说，客户端发起 Connection:upgrade 就表明这是一个连接升级的请求，如果服务器决定升级这次连接，就会返回一个 101 Switching Protocols 响应状态码，和一个要切换到的协议的头部字段 Upgrade。如果服务器没有（或者不能）升级这次连接，它会忽略客户端发送的 Upgrade 头部字段，返回一个常规的响应：例如返回 200。
• 管理持久连接
  我们上面说持久连接有两种方式，一种是 HTTP 1.0 + Keep-Alive ；一种是 HTTP 1.1 + persistent。

Connection: Keep-Alive
Keep-Alive: timeout=10,max=500
1
2

  在 HTTP 1.0 + Keep-Alive 这种方式下，客户端可以通过包含 Connection：Keep-Alive 首部请求将一条连接保持在打开状态。

  这里需要注意⚠️一点：Keep-Alive 首部只是将请求保持在活跃状态，发出 Keep-Alive 请求之后，客户端和服务器不一定会同意进行 Keep-Alive 会话。它们可以在任何时刻关闭空闲的 Keep-Alive 连接，并且客户端和服务器可以限制 Keep-Alive 连接所处理事务的数量。

  Keep-Alive 这个标头有下面几种选项：

• timeout：这个参数估计了服务器希望将连接保持在活跃状态的时间。
• max ：这个参数是跟在 timeout 参数后面的，它表示的是服务器还能够为多少个事务打开持久连接。
• Keep-Alive 这个首部是可选的，但是只有在提供 Connection：Keep-Alive 时才能使用它。

Keep-Alive 使用限制和规则
  在 HTTP/1.0 中，Keep-Alive 并不是默认使用的，客户端必须发送一个 Connection：Keep-Alive 请求首部来激活 Keep-Alive 连接。

  通过检测响应中是否含有 Connection：Keep-Alive 首部字段，客户端可以判断服务器是否在发出响应之后关闭连接。

  代理和网管必须执行 Connection 首部规则，它们必须在将报文转发出去或者将缓存之前，删除 Connection 首部中的首部字段和 Connection 首部自身，因为 Connection 是一个 Hop-by-Hop 首部，这个首部说的是只对单次转发有效，会因为转发给缓存/代理服务器而失效。

  严格来说，不应该与无法确定是否支持 Connection 首部的代理服务器建立 Keep-Alive 连接，以防止出现哑代理问题；

代理服务器

代理服务器就是代替客户端去获取网络信息的一种媒介，通俗一点就是网络信息的中转站。

为什么我们需要代理服务器？

  最广泛的一种用处是我们需要使用代理服务器来替我们访问一些我们客户端无法直接访问的网站。除此之外，代理服务器还有很多功能，比如缓存功能，可以降低费用，节省带宽；对信息的实时监控和过滤，代理服务器相对于目标服务器（最终获取信息的服务器）来说，也是一个客户端，它能够获取服务器提供的信息，代理服务器相对于客户端来说，它是一个服务器，由它来决定提供哪些信息给客户端，以此来达到监控和过滤的功能。

哑代理问题
  哑代理问题主要是，http客户端和服务器端进行通信时，会经过代理服务器，但是代理服务器不一定支持keep-alive。

哑代理问题出现就出现在代理服务器上，再细致一点就是出现在不能识别 Connection 首部的代理服务器，而且不知道在发出请求之后会删除 Connection 首部的代理服务器；
Proxy-Connection 解决哑代理
  网景公司提出了一种使用 Proxy-Connection 标头的办法，首先浏览器会向代理发送 Proxy-Connection 扩展首部，而不是官方支持的 Connection 首部。如果代理服务器是哑代理的话，它会直接将 Proxy-Connection 发送给服务器，而服务器收到 Proxy-Connection 的话，就会忽略这个首部，这样不会带来任何问题。如果是一个聪明的代理服务器，在收到 Proxy-Connection 的时候，就会直接将 Connection 替换掉 Proxy-Connection ，再发送给服务器。
HTTP/1.1 持久连接
  HTTP/1.1 逐渐停止了对 Keep-Alive 连接的支持，用一种名为 persistent connection 的改进型设计取代了 Keep-Alive ，这种改进型设计也是持久连接，不过比 HTTP/1.0 的工作机制更优。

  与 HTTP/1.0 的 Keep-Alive 连接不同，HTTP/1.1 在默认情况下使用的就是持久连接。除非特别指明，否则 HTTP/1.1 会假定所有连接都是持久连接。如果想要在事务结束后关闭连接的话，就需要在报文中显示添加一个 Connection：close 首部。这是与以前的 HTTP 协议版本很重要的区别。

  使用 persistent connection 也会有一些限制和规则：

• 首先，发送了 Connection: close 请求后，客户端就无法在这条连接上发送更多的请求。这同时也可以说，如果客户端不想发送其他请求，就可以使用 Connection：close 关闭连接。
• HTTP/1.1 的代理必须能够分别管理客户端和服务器的持久连接 ，每个持久连接都只适用于单次传输。
• 客户端对任何服务器或者代理最好只维护两条持久连接，以防止服务器过载。
• 只有实体部分的长度和相应的 Content-Length保持一致时，或者使用分块传输编码的方式时，连接才能保持长久。

管道化连接
  HTTP/1.1 允许在持久连接上使用请求管道。这是相对于 Keep-Alive 连接的又一个性能优化。管道就是一个承载 HTTP 请求的载体，我们可以将多个 HTTP 请求放入管道，这样能够降低网络的环回时间，提升性能。下图是使用串行连接、并行连接、管道化连接的示意图：

  使用管道化的连接也有几处限制：

• 如果 HTTP 客户端无法确认连接是持久的，就不应该使用管道。
• 必须按照与请求的相同顺序回送 HTTP 响应，因为 HTTP 没有序号这个概念，所以一旦响应失序，就没办法将其与请求匹配起来了。
• HTTP 客户端必须做好连接会在任何时刻关闭的准备，还要准备好重发所有未完成的管道化请求。

HTTP 关闭连接
  所有 HTTP 客户端、服务器或者代理都可以在任意时刻关闭一条 HTTP 传输连接。通常情况下会在一次响应后关闭连接，但是保不准也会在 HTTP 事务的过程中出现。

  但是，服务器无法确定在关闭的那一刻，客户端有没有数据要发送，如果出现这种情况，客户端就会在进行数据传输的过程中发生了写入错误。

  即使在不出错的情况下，连接也可以在任意时刻关闭。如果在事务传输的过程中出现了连接关闭情况，就需要重新打开连接进行重试。如果是单条连接还好说，如果是管道化连接，就比较糟糕，因为管道化连接会把大量的连接丢在管道中，此时如果服务器关闭，就会造成大量的连接未响应，需要重新调度。

  如果一个 HTTP 事务不管执行一次还是执行 n 次，它得到的结果始终是一样的，那么我们就认为这个事务是幂等的，一般 GET、HEAD、PUT、DELETE、TRACE 和 OPTIONS方法都认为是幂等的。客户端不应该以管道化的方式发送任何非幂等请求，比如 POST，否则就会造成不确定的后果。

  由于 HTTP 使用 TCP 作为传输层的协议，所以 HTTP 关闭连接其实还是 TCP 关闭连接的过程。

HTTP 关闭连接一共分为三种情况：完全关闭、半关闭和正常关闭。

  应用程序可以关闭 TCP 输入和输出信道中的任何一个，或者将二者同时关闭。调用套接字 close() 方法会讲输入和输出同时关闭，这就被称为完全关闭。还可以调用套接字的 shutdown 方法单独关闭输入或者输出信道，这被称为半关闭。HTTP 规范建议当客户端和服务器突然需要关闭连接的时候，应该正常关闭，但是它没有说如何去做。

参考文章：https://mp.weixin.qq.com/s/MksdIMNCdL4CRfJS5Q-gMQ

HTTPS 与 HTTP的区别

  HTTP：是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。

  HTTPS：是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

  HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。

  HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。简单来说，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。

HTTPS和HTTP的区别主要如下：

1. https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2. http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3. http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4. http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

HTTPS 的原理，客户端为什么信任第三方证书

客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤，如图所示。
（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。
（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。
（3）客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。
（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。
（5）Web服务器利用自己的私钥解密出会话密钥。
（6）Web服务器利用会话密钥加密与客户端之间的通信。

Q：HTTPS 客户端验证 服务端证书流程
证书预置和申请
1：客户端浏览器会预置根证书， 里面包含CA公钥
2：服务器去CA申请一个证书
3： CA用自己的签名去签一个证书，指纹信息保存在证书的数字摘要里面， 然后发送给服务器

一次访问流程（简化）
1： 客户端 sayHello
2： 服务器返回证书
3-1： 客户端验证证书内容有效性（过期时间， 域名是否相同等）
3-2： 验证证书的有效性 （是否被串改）， 通过本地根证书的CA公钥解密数字摘要，看是否匹配。
3-3：如果数字签名验证通过， 就可以使用服务器证书里面提供的公钥进行下一步通信。

https优点
  尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：
（1）使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
（2）HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
（3）HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
（4）谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。

https缺点
虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：
（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；
（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
（4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

HTTP 方法

HTTP/1.1协议中共定义了八种方法（有时也叫“动作”），来表明Request-URL指定的资源不同的操作方式；
HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法；
HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法；

1、OPTIONS
返回服务器针对特定资源所支持的HTTP请求方法，也可以利用向web服务器发送‘*’的请求来测试服务器的功能性
2、HEAD
向服务器索与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以再不必传输整个响应内容的情况下，就可以获取包含在响应小消息头中的元信息。
3、GET
向特定的资源发出请求。注意：GET方法不应当被用于产生“副作用”的操作中，例如在Web Application中，其中一个原因是GET可能会被网络蜘蛛等随意访问。Loadrunner中对应get请求函数：web_link和web_url
4、POST
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。 Loadrunner中对应POST请求函数：web_submit_data,web_submit_form
5、PUT
向指定资源位置上传其最新内容
6、DELETE
请求服务器删除Request-URL所标识的资源
7、TRACE
回显服务器收到的请求，主要用于测试或诊断
8、CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

注意：
1）方法名称是区分大小写的，当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Mothod Not Allowed）；当服务器不认识或者不支持对应的请求方法时，应返回状态码501（Not Implemented）。
2）HTTP服务器至少应该实现GET和HEAD/POST方法，其他方法都是可选的，此外除上述方法，特定的HTTP服务器支持扩展自定义的方法。

HTTP 请求/响应的步骤：

客户端连接到Web服务器->发送Http请求->服务器接受请求并返回HTTP响应->释放连接TCP连接->客户端浏览器解析HTML内容

1、客户端连接到Web服务器
  一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.baidu.com

2、发送HTTP请求
  通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。

3、服务器接受请求并返回HTTP响应
  Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。
4、释放连接TCP连接
  若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;

5、客户端浏览器解析HTML内容
  客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。

客户端发送一个HTTP请求到服务器的请求消息包括以下格式
请求行（request line）、请求头部（header）、空行和请求数据四个部分组成。

请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本
Get请求例子，使用Charles抓取的request：

GET /562f25980001b1b106000338.jpg HTTP/1.1
Host    img.mukewang.com
User-Agent    Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept    image/webp,image/*,*/*;q=0.8
Referer    http://www.imooc.com/
Accept-Encoding    gzip, deflate, sdch
Accept-Language    zh-CN,zh;q=0.8
1
2
3
4
5
6
7

第一部分：请求行，用来说明请求类型,要访问的资源以及所使用的HTTP版本.
GET说明请求类型为GET,[/562f25980001b1b106000338.jpg]为要访问的资源，该行的最后一部分说明使用的是HTTP1.1版本。

第二部分：请求头部，紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息
从第二行起为请求头部，HOST将指出请求的目的地.User-Agent,服务器端和客户端脚本都能访问它,它是浏览器类型检测逻辑的重要基础.该信息由你的浏览器来定义,并且在每个请求中自动发送等等

第三部分：空行，请求头部后面的空行是必须的
即使第四部分的请求数据为空，也必须有空行。

第四部分：请求数据也叫主体，可以添加任意的其他数据。
这个例子的请求数据为空。

POST请求例子，使用Charles抓取的request：

POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive

name=Professional%20Ajax&publisher=Wiley
1
2
3
4
5
6
7
8

第一部分：请求行，第一行明了是post请求，以及http1.1版本。
第二部分：请求头部，第二行至第六行。
第三部分：空行，第七行的空行。
第四部分：请求数据，第八行。

HTTP请求消息Response

  一般情况下，服务器接收并处理客户端发过来的请求后会返回一个HTTP的响应消息。HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文

第一部分：状态行，由HTTP协议版本号， 状态码， 状态消息 三部分组成。
第一行为状态行，（HTTP/1.1）表明HTTP版本为1.1版本，状态码为200，状态消息为（ok）

第二部分：消息报头，用来说明客户端要使用的一些附加信息
第二行和第三行为消息报头，
Date:生成响应的日期和时间；Content-Type:指定了MIME类型的HTML(text/html),编码类型是UTF-8

第三部分：空行，消息报头后面的空行是必须的
第四部分：响应正文，服务器返回给客户端的文本信息。
空行后面的html部分为响应正文。

HTTP 异常状态码

200 OK 当您的操作将在响应正文中返回数据时，出现此结果。

204 No Content 当您的操作成功，但不在响应正文中返回数据时，出现此结果。

304 Not Modified（重定向） 当测试实体自上次检索以来是否被修改时，出现此结果。

403 Forbidden 客户端错误

401 Unauthorized 客户端错误

413 Payload Too Large（客户端错误） 当请求长度过长时，出现此结果。

400 BadRequest（客户端错误） 当参数无效时，出现此结果。

404 Not Found（客户端错误） 当资源不存在时，出现此结果。

405 Method Not Allowed（客户端错误）由于方法和资源组合不正确而出现此错误。 例如，您不能对一个实体集合使用 DELETE 或 PATCH。

412 Precondition Failed 客户端错误

501 Not Implemented（服务器错误） 当未实施某个请求的操作时，出现此结果。

503 Service Unavailable（服务器错误） 当 Web API 服务不可用时，出现此结果。

GET与POST

  “get”方法提交的数据会直接填充在请求报文的URL上，如“ https://www.baidu.com/s?ie=utf-8&f=8&rsv_bp=1 ” “？”问号划分域名和get提交的参数，A=B中的A是参数名，B是参数值，多个参数之间用&进行分割，如果参数值是中文，则会转换成诸如%ab%12加密16进制码。一般来说，浏览器处理的URL最大限度长度为1024B（不同浏览器不一样），所以GET方法提交参数长度有限制。

   “post”方法提交的数据会附在正文上，一般请求正文的长度是没有限制的，但表单中所能处理的长度一般为100k（不同协议不同浏览器不一样）,而且需要考虑下层报文的传输效率，不推荐过长。

  所以GET方法可以用来传输一些可以公开的参数信息，解析也比较方便，如百度的搜索的关键词，而POST方法可以用来提交一个用户的敏感信息（如果不使用HTTPS加密，报文正文仍旧是明文，容易被人截获读取）

HTTP 长连接短连接使用场景

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

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

  在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据 的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。

  Keep-Alive 不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如 Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。 HTTP 协议的长连接和短连接，实质上是 TCP 协议的长连接和短连接。

长连接和短连接的应用场景
  长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个 TCP 连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多， 所以每个操作完后都不断开，下次处理时直接发送数据包就 OK 了，不用建立 TCP 连接。例如： 数据库的连接用长连接， 如果用短连接频繁的通信会造成 socket 错误，而且频繁的 socket创建也是对资源的浪费。

  而像 WEB 网站的 http 服务一般都用短链接，因为长连接对于服务端来说会耗费一定的 资源，而像 WEB 网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源， 如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连接。

ARP 攻击

ARP协议

  ARP协议（address resolution protocol）地址解析协议；

  一台主机和另一台主机通信，要知道目标的IP地址，但是在局域网中传输数据的网卡却不能直接识别IP地址，所以用ARP解析协议将IP地址解析成MAC地址。ARP协议的基本功能就是通过目标设备的IP地址，来查询目标设备的mac地址。

  在局域网的任意一台主机中，都有一个ARP缓存表，里面保存本机已知的此局域网中各主机和路由器的IP地址和MAC地址的对照关系。ARP缓存表的生命周期是有时限的（一般不超过20分钟）。

举个例子：假设局域网中有四台主机

  主机A想和主机B通信，主机A会先查询自己的ARP缓存表里有没有B的联系方式，有的话，就将mac-b地址封装到数据包外面，发送出去。没有的话，A会向全网络发送一个ARP广播包，大声询问：我的IP地址是192.168.0.2，硬件地址是mac-a，我想知道IP地址是192.168.0.3的硬件地址是多少？ 此时，局域网内所有主机都收到了，B收到后会单独私密回应：我是192.168.0.3，我的硬件地址是mac-b，其他主机不会理A的；此时A知道了B的信息，同时也会动态的更新自身的缓存表。

Q：既然ARP协议是解析ip地址到mac地址，那通讯软件上我不知道对方的ip地址，怎么能给他发信息？
  这就牵涉到服务器了，以QQ为例，A登陆自己的QQ就是向服务器发送登陆请求，此时服务器会核实A的账号和密码，并获取它的ip地址，存在服务器中，并把自己的ip地址给A；同样B登陆也是如此，此时服务器就有A、B二者的IP地址了，如果A发信息给B，那么信息会先到服务器中，然后服务器找到B的ip地址，将它发送给B；
  等于A、B的通信时通过QQ服务器进行的，A、B都不知道对方的IP地址，只知道服务器的地址，他们将信息给服务器，由服务器来进行转发；

ARP攻击的发现

首先诊断是否为ARP病毒攻击
1、当发现上网明显变慢，或者突然掉线时，我们可以用arp -a命令来检查ARP表：(点击“开始”按钮-选择“运行”-输入“cmd”点击"确定"按钮，在窗口中输入“arp -a”命令)如果发现网关的MAC地址发生了改变，或者发现有很多IP指向同一个物理地址，那么肯定就是ARP欺骗所致。这时可以通过”arp -d“清除arp列表，重新访问。

2、利用ARP防火墙类软件(如：360ARP防火墙、AntiARPSniffer等)。

如何判断交换机是否受到ARP攻击以及处理方式

如果网络受到了ARP攻击，可能会出现如下现象：
1、用户掉线、频繁断网、上网慢、业务中断或无法上网。
2、设备CPU占用率较高、设备托管、下挂设备掉线、设备主备状态震荡、设备端口指示灯红色快闪。
3、Ping有时延、丢包或不通。

局域网内的机器遭到ARP病毒欺骗攻击，如果找到源头的机器，将其病毒或木马杀掉，局域网内机器就会恢复正常，那么如何才能快速定位到攻击的源头机器呢?

1、用arp -a命令。当发现上网明显变慢，或者突然掉线时，我们可以用arp -a命令来检查ARP表。如果发现网关的MAC地址发生了改变，或者发现有很多IP地址指向同一个MAC地址，那么肯定就是ARP攻击所致。

2、利用彩影ARP防火墙软件查看。如果网卡是处于混杂模式或者ARP请求包发送的速度大或者ARP请求包总量非常大，判断这台机器有可能就是“元凶”。定位好机器后，再做病毒信息收集工作。

3、通过路由器的“系统历史记录”查看。由于ARP攻击的木马程序发作的时候会发出大量的数据包导致局域网通讯阻塞以及其自身处理能力的限制，用户会感觉上网速度越来越慢。当ARP攻击的木马程序停止运行时，用户会恢复从路由器上网，切换过程中用户会再断一次线。这个消息代表了用户的MAC地址发生了变化，在ARP攻击木马开始运行的时候，局域网所有主机的MAC地址更新为病毒主机的MAC地址(即所有信息的MAC New地址都一致为病毒主机的MAC地址)，同时在路由器的“用户统计”中看到所有用户的MAC地址信息都一样。

  如果是在路由器的“系统历史记录”中看到大量MAC Old地址都一致，则说明局域网内曾经出现过ARP攻击(ARP攻击的木马程序停止运行时,主机在路由器上恢复其真实的MAC地址)。

ARP攻击过程

攻击方式
1、 简单的诈骗攻击

  这是对比多见的攻击，经过发送伪造的ARP包来诈骗路由和方针主机，让方针主机认为这是一个合法的主机，便完成了诈骗，这种诈骗多发生在同一网段内，因为路由不会把本网段的包向外转发，当然完成不一样网段的攻击也有办法，便要经过ICMP协议来告诉路由器从头挑选路由。

2、根据ARP的DOS

  这是新呈现的一种攻击办法，D.O.S又称拒绝服务攻击，当大量的衔接请求被发送到一台主机时，因为主机的处理才能有限，不能为正常用户提供服务，便呈现拒绝服务。这个过程中假如运用ARP来躲藏自己，在被攻击主机的日志上就不会呈现真实的IP攻击，也不会影响到本机。

3、MAC Flooding

  这是一个对比风险的攻击，能够溢出交流机的ARP表，使全部网络不能正常通讯。

4、交流环境的嗅探

  在开始的小型局域网中咱们运用HUB来进行互连，这是一种广播的办法，每个包都会经过网内的每台主机，经过运用软件，就能够嗅谈到全部局域网的数据。现在的网络多是交流环境，网络内数据的传输被锁定的特定方针。既已断定的方针通讯主机，在ARP诈骗的根底之上，能够把自己的主机伪形成一个中心转发站来监听两台主机之间的通讯。

ARP攻击的防护

1、 ARP 高速缓存超时设置
  在ARP高速缓存中的表项一般都要设置超时值，缩短这个这个超时值能够有用的避免ARP表的溢出。

2、 IP+MAC访问操控 -----推荐使用
  单纯依托IP或MAC来树立信赖联系是不安全，抱负的安全联系树立在IP+MAC的根底上，这也是咱们校园网上网有必要绑定IP和MAC的因素之一。

3、 静态ARP缓存表
  每台主机都有一个暂时寄存IP-MAC的对应表ARP攻击就经过更改这个缓存来到达诈骗的意图，运用静态的ARP来绑定正确的MAC是一个有用的办法，在命令行下运用arp -a能够检查当时的ARP缓存表。

4、自动查询
  在某个正常的时间，做一个IP和MAC对应的数据库，以后定时检查当时的IP和MAC对应联系是否正常，定时检查交流机的流量列表，检查丢包率。

  ARP本省不能形成多大的损害，一旦被联系使用，其风险性就不可估量，因为ARP自身的疑问，使得防备ARP的攻击很棘手，经常检查当时的网络状况，监控流量对一个站长来说是个很好的风气

NAT 原理

参考文章：
NAT技术基本原理与应用

  公有IP地址：也叫全局地址，是指合法的IP地址，它是由NIC（网络信息中心）或者ISP(网络服务提供商)分配的地址，对外代表一个或多个内部局部地址，是全球统一的可寻 址的地址。

  私有IP地址：也叫内部地址，属于非注册地址，专门为组织机构内部使用。因特网分配编号委员会（IANA）保留了3块IP地址做为私有IP地址：

10.0.0.0 ——— 10.255.255.255
172.16.0.0——— 172.31.255.255
192.168.0.0——— 192.168.255.255

  地址池：地址池是有一些外部地址（全球唯一的IP地址）组合而成，我们称这样的一个地址集合为地址池。在内部网络的数据包通过地址转换到达外部网络时，将会在地址池中选择某个IP地址作为数据包的源IP地址，这样可以有效的利用用户的外部地址，提高访问外部网络的能力。

NAT是什么

NAT：英文全称是“Network Address Translation”，中文意思是“网络地址转换”，它是一个IETF(Internet Engineering Task Force, Internet工程任务组)标准，允许一个整体机构以一个公用IP（Internet Protocol）地址出现在Internet上。顾名思义，它是一种把内部私有网络地址（IP地址）翻译成合法网络IP地址的技术，如下图所示。因此我们可以认为，NAT在一定程度上，能够有效的解决公网地址不足的问题。

  简单地说，NAT就是在局域网内部网络中使用内部地址，而当内部节点要与外部网络进行通讯时，就在网关（可以理解为出口，打个比方就像院子的门一样）处，将内部地址替换成公用地址，从而在外部公网（internet）上正常使用，NAT可以使多台计算机共享Internet连接，这一功能很好地解决了公共 IP地址紧缺的问题。通过这种方法，可以只申请一个合法IP地址，就把整个局域网中的计算机接入Internet中。这时，NAT屏蔽了内部网络，所有内部网计算机对于公共网络来说是不可见的，而内部网计算机用户通常不会意识到NAT的存在。如下图所示。这里提到的内部地址，是指在内部网络中分配给节点的私有IP地址，这个地址只能在内部网络中使用，不能被路由转发。

  NAT 功能通常被集成到路由器、防火墙、ISDN路由器或者单独的NAT设备中。比如Cisco路由器中已经加入这一功能，网络管理员只需在路由器的IOS中设置NAT功能，就可以实现对内部网络的屏蔽。再比如防火墙将WEB Server的内部地址192.168.1.1映射为外部地址202.96.23.11，外部访问202.96.23.11地址实际上就是访问访问 192.168.1.1。此外，对于资金有限的小型企业来说，现在通过软件也可以实现这一功能。Windows 98 SE、Windows 2000 都包含了这一功能。

NAT分类

  NAT有三种类型：静态NAT(Static NAT)、动态地址NAT(Pooled NAT)、网络地址端口转换NAPT（Port-Level NAT）。
静态NAT
  通过手动设置，使 Internet 客户进行的通信能够映射到某个特定的私有网络地址和端口。如果想让连接在 Internet 上的计算机能够使用某个私有网络上的服务器（如网站服务器）以及应用程序（如游戏），那么静态映射是必需的。静态映射不会从 NAT 转换表中删除。
  如果在 NAT 转换表中存在某个映射，那么 NAT 只是单向地从 Internet 向私有网络传送数据。这样，NAT 就为连接到私有网络部分的计算机提供了某种程度的保护。但是，如果考虑到 Internet 的安全性，NAT 就要配合全功能的防火墙一起使用。

  对于以上网络拓扑图，当内网主机 10.1.1.1如果要与外网的主机201.0.0.11通信时，主机（IP：10.1.1.1）的数据包经过路由器时，路由器通过查找NAT table 将IP数据包的源IP地址（10.1.1.1）改成与之对应的全局IP地址（201.0.0.1），而目标IP地址201.0.0.11保持不变，这样，数据包就能到达201.0.0.11。而当主机HostB(IP:201.0.0.11) 响应的数据包到达与内网相连接的路由器时，路由器同样查找NAT table，将IP数据包的目的IP 地址改成10.1.1.1，这样内网主机就能接收到外网主机发过来的数据包。在静态NAT方式中，内部的IP地址与公有IP地址是一种一一对应的映射关系，所以，采用这种方式的前提是，机构能够申请到足够多的全局IP地址。
动态NAT
  动态地址NAT只是转换IP地址，它为每一个内部的IP地址分配一个临时的外部IP地址，主要应用于拨号，对于频繁的远程联接也可以采用动态NAT。当远程用户联接上之后，动态地址NAT就会分配给他一个IP地址，用户断开时，这个IP地址就会被释放而留待以后使用。

  动态NAT方式适合于 当机构申请到的全局IP地址较少，而内部网络主机较多的情况。内网主机IP与全局IP地址是多对一的关系。当数据包进出内网时，具有NAT功能的设备对IP数据包的处理与静态NAT的一样，只是NAT table表中的记录是动态的，若内网主机在一定时间内没有和外部网络通信，有关它的IP地址映射关系将会被删除，并且会把该全局IP地址分配给新的IP数据包使用，形成新的NAT table映射记录。

网络地址端口转换NAPT
  网络地址端口转换NAPT（Network Address Port Translation）则是把内部地址映射到外部网络的一个IP地址的不同端口上。它可以将中小型的网络隐藏在一个合法的IP地址后面。NAPT与 动态地址NAT不同，它将内部连接映射到外部网络中的一个单独的IP地址上，同时在该地址上加上一个由NAT设备选定的端口号。

NAPT是使用最普遍的一种转换方式，它又包含两种转换方式：SNAT和DNAT。

(1)源NAT（Source NAT，SNAT）：修改数据包的源地址。源NAT改变第一个数据包的来源地址，它永远会在数据包发送到网络之前完成，数据包伪装就是一具SNAT的例子。

(2)目的NAT（Destination NAT，DNAT）：修改数据包的目的地址。Destination NAT刚好与SNAT相反，它是改变第一个数据包的目的地地址，如平衡负载、端口转发和透明代理就是属于DNAT。

源NAT举例：对于以上网络拓扑图，内网的主机数量比较多，但是该组织只有一个合法的IP地址，当内网主机（10.1.1.3）往外发送数据包时，则需要修改数据包的IP地址和TCP/UDP端口号，例如将

源IP：10.1.1.3

源port：1493

改成

源IP：201.0.0.1

源port：1492（注意：源端口号可以与原来的一样也可以不一样）

当外网主机（201.0.0.11）响应内网主机（10.1.1.3）时，应将：

目的IP：201.0.0.1

目的port：1492

改成

目的IP：10.1.1.3

目的port：1493

  这样，通过修改IP地址和端口的方法就可以使内网中所有的主机都能访问外网，此类NAT适用于组织或机构内只有一个合法的IP地址的情况，也是动态NAT的一种特例。

  目的NAT举例：这种方式适用于内网的某些服务器需要为外网提供某些服务的情况。例如以上拓 扑结构，内网服务器群（ip地址分别为：10.1.1.1,10.1.1.2,10.1.1.3等）需要为外网提供WEB 服务，当外网主机HostB访问内网时，所发送的数据包的目的IP地址为10.1.1.127，端口号为：80，当该数据包到达内网连接的路由器时，路由器查找NAT table，路由器通过修改目的IP地址和端口号，将外网的数据包平均发送到不同的主机上（10.1.1.1,10.1.1.2,10.1.1.3等），这样就实现了负载均衡。

NAT原理

地址转换+连接跟踪+端口转换
地址转换
  NAT的基本工作原理是，当私有网主机和公共网主机通信的IP包经过NAT网关时，将IP包中的源IP或目的IP在私有IP和NAT的公共IP之间进行转换。

  如下图所示，NAT网关有2个网络端口，其中公共网络端口的IP地址是统一分配的公共 IP，为202.20.65.5；私有网络端口的IP地址是保留地址为192.168.1.1。私有网中的主机192.168.1.2向公共网中的主机202.20.65.4发送了1个IP包(Dst=202.20.65.4,Src=192.168.1.2)。

  NAT Gateway的公共IP并转发到公共网，此时IP包（Dst=202.20.65.4，Src=202.20.65.5）中已经不含任何私有网IP的信息。由于IP包的源IP已经被转换成NAT Gateway的公共IP，Web Server发出的响应IP包（Dst= 202.20.65.5,Src=202.20.65.4）将被发送到NAT Gateway。

  这时，NAT Gateway会将IP包的目的IP转换成私有网中主机的IP，然后将IP包（Des=192.168.1.2，Src=202.20.65.4）转发到私有网。对于通信双方而言，这种地址的转换过程是完全透明的。转换示意图如下。

  如果内网主机发出的请求包未经过NAT，那么当Web Server收到请求包，回复的响应包中的目的地址就是私有网络IP地址，在Internet上无法正确送达，导致连接失败。
连接跟踪
  在上述过程中，NAT Gateway在收到响应包后，就需要判断将数据包转发给谁。此时如果子网内仅有少量客户机，可以用静态NAT手工指定；但如果内网有多台客户机，并且各自访问不同网站，这时候就需要连接跟踪（connection track）。如下图所示：

  在NAT Gateway收到客户机发来的请求包后，做源地址转换，并且将该连接记录保存下来，当NAT Gateway收到服务器来的响应包后，查找Track Table，确定转发目标，做目的地址转换，转发给客户机。
端口转换
  以上述客户机访问服务器为例，当仅有一台客户机访问服务器时，NAT Gateway只须更改数据包的源IP或目的IP即可正常通讯。但是如果Client A和Client B同时访问Web Server，那么当NAT Gateway收到响应包的时候，就无法判断将数据包转发给哪台客户机，如下图所示。

  如果两客户机访问同一服务器的源端口不同，那么在Track Table里加入端口信息即可区分，如果源端口正好相同，那么在实行SNAT和DNAT的同时对源端口也要做相应的转换，如下图所示。

NAT应用

NAT主要可以实现以下几个功能：数据包伪装、平衡负载、端口转发和透明代理。

数据伪装: 可以将内网数据包中的地址信息更改成统一的对外地址信息，不让内网主机直接暴露在因特网上，保证内网主机的安全。同时，该功能也常用来实现共享上网。例如，内网主机访问外网时，为了隐藏内网拓扑结构，使用全局地址替换私有地址。

端口转发: 当内网主机对外提供服务时，由于使用的是内部私有IP地址，外网无法直接访问。因此，需要在网关上进行端口转发，将特定服务的数据包转发给内网主机。例如公司小王在自己的服务器上架设了一个Web网站，他的IP地址为192.168.0.5，使用默认端口80，现在他想让局域网外的用户也能直接访问他的Web站点。利用NAT即可很轻松的解决这个问题，服务器的IP地址为210.59.120.89，那么为小王分配一个端口，例如81，即所有访问210.59.120.89:81的请求都自动转向192.168.0.5:80，而且这个过程对用户来说是透明的。

负载平衡:目的地址转换NAT可以重定向一些服务器的连接到其他随机选定的服务器。例如1.2.3所讲的目的NAT的例子。

失效终结:目的地址转换NAT可以用来提供高可靠性的服务。如果一个系统有一台通过路由器访问的关键服务器，一旦路由器检测到该服务器当机，它可以使用目的地址转换NAT透明的把连接转移到一个备份服务器上，提高系统的可靠性。

透明代理:例如自己架设的服务器空间不足，需要将某些链接指向存在另外一台服务器的空间；或者某台计算机上没有安装IIS服务，但是却想让网友访问该台计算机上的内容，这个时候利用IIS的Web站点重定向即可轻松的帮助我们搞定。

NAT缺陷

  NAT在最开始的时候是非常完美的，但随着网络的发展，各种新的应用层出不穷，此时NAT也暴露出了缺点。NAT的缺陷主要表现在以下几方面：

(1) 不能处理嵌入式IP地址或端口

  NAT设备不能翻译那些嵌入到应用数据部分的IP地址或端口信息，它只能翻译那种正常位于IP首部中的地址信息和位于TCP/UDP首部中的端口信息，如下图,由于对方会使用接收到的数据包中嵌入的地址和端口进行通信，这样就可能产生连接故障，如果通信双方都是使用的公网IP，这不会造成什么问题，但如果那个嵌入式地址和端口是内网的，显然连接就不可能成功，原因就如开篇所说的一样。MSN Messenger的部分功能就使用了这种方式来传递IP和端口信息，这样就导致了NAT设备后的客户端网络应用程序出现连接故障。

(2) 不能从公网访问内部网络服务

  由于内网是私有IP，所以不能直接从公网访问内部网络服务，比如WEB服务，对于这个问题，我们可以采用建立静态映射的方法来解决。比如有一条静态映射，是把218.70.201.185:80与192.168.0.88:80映射起的，当公网用户要访问内部WEB服务器时，它就首先连接到218.70.201.185:80，然后NAT设备把请求传给192.168.0.88:80，192.168.0.88把响应返回NAT设备，再由NAT设备传给公网访问用户。

(3) 收发端口不同：有一些应用程序虽然是用A端口发送数据的，但却要用B端口进行接收，不过NAT设备翻译时却不知道这一点，它仍然建立一条针对A端口的映射，结果对方响应的数据要传给B端口时，NAT设备却找不到相关映射条目而会丢弃数据包。

(4) 一些P2P应用在NAT后无法进行
  对于那些没有中间服务器的纯P2P应用（如电视会议，娱乐等）来说，如果大家都位于NAT设备之后，双方是无法建立连接的。因为没有中间服务器的中转，NAT设备后的P2P程序在NAT设备上是不会有映射条目的，也就是说对方是不能向你发起一个连接的。现在已经有一种叫做P2P NAT穿越的技术来解决这个问题。

  NAT技术无可否认是在ipv4地址资源的短缺时候起到了缓解作用；在减少用户申请ISP服务的花费和提供比较完善的负载平衡功能等方面带来了不少好处。但是在ipv4地址在以后几年将会枯竭，NAT技术不能改变ip地址空间不足的本质。然而在安全机制上也潜在着威胁，在配置和管理上也是一个挑战。如果要从根本上解决ip地址资源的问题，ipv6才是最根本之路。在ipv4转换到ipv6的过程中，NAT技术确实是一个不错的选择，相对其他的方案优势也非常明显。

DNS 服务器与提供内容的服务器的区别

DNS：域名系统（服务）协议

  域名系统（服务）协议（DNS）是一种分布式网络目录服务，主要用于域名与 IP 地址的相互转换，以及控制因特网的电子邮件的发送。大多数因特网服务依赖于 DNS 而工作，一旦 DNS 出错，就无法连接 Web 站点，电子邮件的发送也会中止。DNS服务主要在广域网中使用。

Web服务器
  Web服务器可以解析(handles)HTTP协议。当Web服务器接收到一个HTTP请求(request)，会返回一个HTTP响应(response)，例如送回一个HTML页面。为了处理一个请求(request)，Web服务器可以响应(response)一个静态页面或图片，进行页面跳转(redirect)，或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的程序例如CGI脚本，JSP(JavaServer Pages)脚本，servlets，ASP(Active Server Pages)脚本，服务器端(server-side)JavaScript，或者一些其它的服务器端(server-side)技术。无论它们(译者注：脚本)的目的如何，这些服务器端(server-side)的程序通常产生一个HTML的响应(response)来让浏览器可以浏览。

DNS 劫持原理和实现

  DNS劫持的原理为：攻击者冒充网关，把受害机的流量欺骗过来，然后充当DNS服务器，由攻击者自己解析域名。这样子就可以随意的解析域名。到达劫持的目的。即dns系统被入侵或人为的修改某些记录,如A记录,用专业的术语来讲就是通过某些手段取得某域名的解析记录控制权，进而修改此域名的解析结果，导致对该域名的访问由原IP地址转入到修改后的指定IP，其结果就是对特定的网址不能访问或访问的是假网址。

  DNS污染：现行标准中 DNS 查询通常使用 UDP 协议并且没有任何验证机制，并且根据惯例查询者会接受第一个返回的结果而抛弃之后的。因此只需监控 53 端口（DNS 标准端口）的 UDP查询数据报并分析，一旦发现敏感查询，则抢先向查询者返回一个伪造的错误结果，从而实现 DNS 污染。
DNS污染并无法阻止正确的DNS解析结果返回，但由于旁路产生的数据包发回的速度较国外DNS服务器发回的快，操作系统认为第一个收到的数据包就是返回结果，从而忽略其后收到的数据包，从而使得DNS污染得逞。

  应对DNS劫持最好的办法就是手动指定DNS服务器地址，可以手动配置电脑上的DNS服务器地址，DNS服务器的地址可以咨询你的宽带运营商，或者使用免费的DNS服务器，国内的114.114.114.114，谷歌提供的8.8.8.8。当然也可以在宽带路由器上配置DHCP服务器，在DHCP服务器中指定好DNS服务器地址，连接该路由器的所有设备都将使用该指定的DNS服务器地址。

对称加密和非对称的区别，非对称加密有哪些

参考文章：对称加密和非对称加密的区别

• 对称加密: 加密和解密的秘钥使用的是同一个.
• 非对称加密: 与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。

对称加密算法：密钥较短，破译困难，除了数据加密标准（DES），另一个对称密钥加密系统是国际数据加密算法（IDEA），它比DES的加密性好，且对计算机性能要求也没有那么高.

优点：算法公开、计算量小、加密速度快、加密效率高

缺点:

  在数据传送前，发送方和接收方必须商定好秘钥，然后 使双方都能保存好秘钥。其次如果一方的秘钥被泄露，那么加密信息也就不安全了。另外，每对用户每次使用对称加密算法时，都需要使用其他人不知道的唯一秘钥，这会使得收、发双方所拥有的钥匙数量巨大，密钥管理成为双方的负担。

常见的对称加密算法有: DES、3DES、Blowfish、IDEA、RC4、RC5、RC6 和 AES

非对称加密算法：公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

  非对称加密算法实现机密信息交换的基本过程是：甲方生成一对密钥并将其中的一把作为公用密钥向其它方公开；得到该公用密钥的乙方使用该密钥对机密信息进行加密后再发送给甲方；甲方再用自己保存的另一把专用密钥对加密后的信息进行解密。甲方只能用其专用密钥解密由其公用密钥加密后的任何信息。

优点：安全

缺点： 速度较慢

  常见的非对称加密算法有: RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）

Hash算法（摘要算法）
  Hash算法特别的地方在于它是一种单向算法，用户可以通过hash算法对目标信息生成一段特定长度的唯一hash值，却不能通过这个hash值重新获得目标信息。因此Hash算法常用在不可还原的密码存储、信息完整性校验等。

常见的摘要算法有: MD2、MD4、MD5、HAVAL、SHA
哈希算法 能达到获取内容的效果 所以也可以称为摘要算法 md5 常用来验证文件 就是这原理

AES 的过程

参考文章：AES 加密算法的原理详解
高级加密标准(AES,Advanced Encryption Standard)为最常见的对称加密算法(微信小程序加密传输就是用这个加密算法的)。对称加密算法也就是加密和解密用相同的密钥，具体的加密流程如下图：


实际中，一般是通过RSA加密AES的密钥，传输到接收方，接收方解密得到AES密钥，然后发送方和接收方用AES密钥来通信。

安全攻击有哪些

安全攻击分为哪些？
一种有用的划分安全攻击的方法是使用被动攻击和主动攻击的划分方法。
被动攻击
  被动攻击的本质就是窃听和监听数据传输。攻击者的目标是获取传输的数据信息。被动攻击的两种形式是消息内容泄露攻击和流量分析攻击。**被动攻击是非常难以检测，因为它们没有改变数据。**尽管如此，防范这些攻击还是切实可行的，通常使用加密的方式来去实现。因此，对付被动攻击的重点是防范而不是检测。

(一）消息内容泄露
  这个我们很容易理解，电话交谈，电子邮件消息和传输文件中都有可能包含敏感或机密的信息。我们需要阻止攻击者获取这些信息。

（二）流量分析
  流量分析攻击更加的巧妙。假设我们已经有一种方法可以掩盖消息内容或者其他信息，确保攻击者即使获取信息，他们也不能从中读取有用的信息，通常掩盖信息的方法是加密。
如果我们已经做了适当的保护，但攻击者仍然可能观察到这些信息的模式。攻击者可以得知其位置和身份，并且得到交换信息的频率和长度。对于猜测信息的性质很有帮助。

主动攻击
  主动攻击包含改写数据流和错误数据流的添加，它可以划分为4类：假冒、重放、改写信息和拒绝服务。
（1）假冒
  即假冒身份，经过实体认证，得到一些权限，进行权限攻击。
（二）重放
  重放涉及被动获取数据单元并按照它之前的顺序重新传输，此外来产生一个非授权的效应。
（三）改写
  是指合法消息的某个部分被篡改，或者消息被延迟，被重排，从而产生非授权效应

（四）拒绝服务
  可以阻止或禁止对通信设备的正常使用和管理。这个攻击可能有一个特殊目标：比如一个实体可能禁止把所有的消息发送到一个特定的目的地；另一种拒绝服务的形式是对整个网络的破坏，是网络瘫痪或消息过载从而丧失网络性能。

DDOS 有哪些，如何防范

  分布式拒绝服务(DDoS: distributed denial-of-service)攻击是恶意破坏目标服务器、服务或网络的正常通信量的企图，其方法是用大量Internet通信量淹没目标或其周围的基础设施。DDoS攻击通过利用多个受损的计算机系统作为攻击流量的来源来达到有效性。被利用的机器可以包括计算机和其他网络资源，如物联网设备。从高层来说，DDoS攻击就像堵塞高速公路的交通堵塞，阻止常规交通到达它想要的目的地。

DDOS攻击过程和目标

Q：DDoS攻击是怎么工作的?

  DDoS攻击要求攻击者获得对在线计算机网络的控制，以便进行攻击。电脑或者其他机器(如物联网设备)被恶意软件感染，每台电脑都变成了僵尸。然后攻击者就可以远程控制这群被称为僵尸网络的机器人。

  一旦建立了僵尸网络，攻击者就可以通过远程控制的方法向每个机器人发送更新的指令，从而指导机器人。当僵尸网络攻击受害者的IP地址时，每个机器人都会向目标发送请求，这可能导致目标服务器或网络溢出容量，导致对正常流量的拒绝服务。因为每个机器人都是一个合法的互联网设备，所以很难将攻击流量与正常流量分开。

Q：DDoS攻击的常见类型是什么?

  不同的DDoS攻击向量针对不同的网络连接组件。为了了解不同的DDoS攻击是如何工作的，有必要了解网络连接是如何建立的。Internet上的网络连接由许多不同的组件或“层”组成。就像从头开始建造房子一样，模型中的每一步都有不同的目的。

  虽然几乎所有的DDoS攻击都涉及用流量淹没目标设备或网络，但攻击可以分为三类。攻击者可能利用一个或多个不同的攻击向量，或基于目标采取的对抗措施的循环攻击向量。

应用层攻击（Application Layer Attacks）

攻击目标:

  有时被称为第7层DDoS攻击(参照OSI模型的第7层)，这些攻击的目标是耗尽目标的资源。攻击针对的是在服务器上生成并响应HTTP请求交付web页面的层。在客户端执行一个HTTP请求很便宜，而且目标服务器响应起来也很昂贵，因为服务器通常必须加载多个文件并运行数据库查询才能创建web页面。第7层攻击很难防御，因为流量很难标记为恶意的。

应用层攻击实例:

HTTP Flood

  这种攻击类似于在web浏览器中一次又一次地在许多不同的计算机上按下refresh——大量的HTTP请求涌向服务器，导致拒绝服务。

  这种类型的攻击范围从简单到复杂。更简单的实现可以使用相同范围的攻击IP地址、引用和用户代理访问一个URL。复杂版本可能会使用大量的攻击IP地址，并使用随机的引用器和用户代理来目标随机url。

协议攻击（Protocol Attacks）

攻击目标:

  协议攻击(也称为状态耗尽攻击)通过消耗web应用服务器或防火墙和负载均衡器等中间资源的所有可用状态表容量，导致服务中断。协议攻击利用协议栈的第3层和第4层的弱点使目标无法访问。

协议攻击的例子:

SYN Flood

  同步洪水类似于供应室的工作人员接收来自商店前面的请求。工作人员接收到请求，然后去获取包，并等待确认，然后再将包带到前面。然后，工作人员在没有确认的情况下得到更多的包请求，直到他们无法携带更多的包，变得不堪重负，请求开始无人应答。

  这种攻击利用TCP握手，通过发送大量具有欺骗源IP地址的TCP“初始连接请求”SYN包给目标。目标机器响应每个连接请求，然后等待握手的最后一步，握手永远不会发生，这会耗尽目标的资源。

容量耗尽攻击（Volumetric Attacks）

攻击目标:

  这类攻击试图通过消耗目标和大型Internet之间的所有可用带宽来造成拥塞。通过使用一种放大形式或另一种产生大量流量的方式(如僵尸网络的请求)将大量数据发送到目标。

放大的例子:

DNS Amplification

  DNS扩增就像如果有人打电话给一家餐馆，说“我要一份套餐，请给我回电话，告诉我我的全部订单”，他们给出的回叫电话号码就是目标顾客的号码。只需很少的努力，就会产生长时间的响应。

  通过向具有欺骗IP地址(目标的实际IP地址)的开放DNS服务器发出请求，目标IP地址然后从服务器接收响应。攻击者构造请求，使DNS服务器用大量数据响应目标。因此，目标接收攻击者初始查询的放大。

DDOS解决方案

Q：怎么才能减轻DDoS攻击?

  减轻DDoS攻击的关键问题是区分攻击和正常通信量。例如，如果一个产品发布让一个公司的网站挤满了热切的客户，那么切断所有的流量就是一个错误。如果该公司突然有一个流量激增的已知不良演员，努力减轻攻击可能是必要的。难点在于区分真正的客户和攻击流量。

  在现代互联网中，DDoS流量有多种形式。流量可以在设计上有所不同，从无欺骗的单源攻击到复杂的自适应多矢量攻击。多矢量DDoS攻击使用多种攻击路径，以不同的方式覆盖目标，可能分散在任何一条轨迹上的缓解工作。同时攻击协议栈的多个层，例如DNS放大(目标层3/4)和HTTP洪水(目标层7)是多向量DDoS的一个例子。

  减轻多矢量DDoS攻击需要多种策略来对抗不同的轨迹。一般来说，攻击越复杂，流量就越难以从正常的流量中分离出来——攻击者的目标是尽可能地融入其中，使缓解的效率尽可能低。不加区别地减少或限制流量的缓解尝试可能会将好的流量与坏的流量一起抛弃，攻击也可能修改和适应以规避对策。为了克服破坏的复杂尝试，分层的解决方案将带来最大的好处。

黑洞的路由

几乎所有网络管理员都可以使用的一种解决方案是创建一个黑洞路由，并将流量引入该路由。最简单的形式是，当在没有特定限制条件的情况下实现黑洞过滤时，合法的和恶意的网络流量都被路由到空路由或黑洞并从网络中删除。如果一个互联网财产正在经历DDoS攻击，该财产的互联网服务供应商(ISP)可能发送所有的网站流量到一个黑洞作为防御。

速度限制

限制服务器在某个时间窗口内接受的请求数量也是减轻拒绝服务攻击的一种方法。虽然速率限制在减缓web抓取器窃取内容和减轻强制登录尝试方面很有用，但它本身可能不足以有效地处理复杂的DDoS攻击。然而，在有效的DDoS缓解策略中，速率限制是一个有用的组成部分。

Web应用程序防火墙

Web应用程序防火墙(WAF)是一种可以帮助减轻第7层DDoS攻击的工具。通过在Internet和原始服务器之间放置WAF, WAF可以充当反向代理，保护目标服务器免受某些类型的恶意通信。通过基于用于识别DDoS工具的一系列规则过滤请求，第7层的攻击可能会受到阻碍。有效WAF的一个关键价值是能够快速实现自定义规则以响应攻击。

Anycast网络扩散

这种缓解方法使用Anycast网络将攻击流量分散到分布式服务器网络上，直到网络吸收流量为止。就像将湍急的河流引导到单独的较小的通道上一样，这种方法将分布式攻击流量的影响分散到可以管理的地方，分散了任何破坏能力。Anycast网络减轻DDoS攻击的可靠性取决于攻击的大小以及网络的大小和效率。