计算机网络知识点扫盲

• ping命令使用的是什么协议

  • ICMP是“Internet Control Message Ptotocol”（Internet控制消息协议）的缩写。它是TCP/IP协议族的一个子协议，用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。

    在网络中经常会使用到ICMP协议。例如经常用于检查网络不通的ping命令，这个ping的过程实际上就是ICMP协议工作的过程。还有跟踪路由的trancert命令也是基于ICMP协议的。

    操作系统规定的ICMP数据包最大尺寸不超过64KB。通常利用这一规定进行主机攻击。即Ping of Death攻击。它的原理是：如果ICMP数据包的尺寸超过64KB上限时，主机就会出现内存分配错误，导致TCP/IP堆栈崩溃，致使主机死机。

    此外，向目标主机长时间、连续、大量地发送ICMP数据包，也会最终使系统瘫痪。大量的ICMP数据包会形成ICMP风暴，使得目标主机耗费大量的CPU资源处理，疲于奔命。

    ping.exe的原理：**向指定的IP地址发送一定长度的数据包，按照约定，若指定IP地址存在的话，会返回同样大小的数据包，当然，若在特定时间内没有返回，就是“超时”，会被认为指定的IP地址不存在。**由于ping使用的是ICMP协议，有些防火墙软件会屏蔽ICMP协议，所以有时候ping的结果只能作为参考，ping不通并不一定说明对方IP不存在。

    IPSec安全策略防ping原理：通过新建一个IPSec策略过滤本机所有的ICMP数据包，这样确实可以有效地防ping，但同时也会留下后遗症。因为ping命令和ICMP协议有着密切的关系。在ICMP协议的应用中包含11种报文格式，其中ping命令就是利用ICMP协议中的“Echo Request”报文进行工作的。

拥塞控制

• 拥塞控制为什么会将门阀下降为原来的一半呢？

  • 迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中的积压处理完。

• 什么是拥塞控制？

  • 防止过多的数据注入网络中，保证路由器或链路不过载。和流量控制类似，都是通过控制发送方发送数据的速率来实现。

• 拥塞控制与流量控制的区别？

  • 拥塞控制是针对网络承受住负荷，是全局性的，涉及到所有的主机，路由器，以及与降低网络传输性能有关的所有因素。而流量控制是点对点的。是接收端对发送端发送数据的控制。

• 拥塞控制的四种算法：慢开始，拥塞避免，快重传，快恢复。

  • 慢开始：在TCP刚建立连接并开始发送数据时，cwnd=1,(最大报文段的长度ＭＳＳ)，（每收到一个ACK确认应答，那么ｃｗｎｄ就加一，这样，每经过一个传输轮次（对所有的报文段的确认），ｃｗｎｄ就翻倍。）每经过一个传输时延（ＲＴＴ），拥塞窗口就翻倍，在ｃｗｎｄ到达门阀之前都是指数增长。
  • 拥塞避免算法：当ｃｗｎｄ＞＝门阀时，就采用拥塞避免的算法，每经过一个传输时延，ｃｗｎｄ就加一，当出现一次网络超时时，就将门阀　置为当前ｃｗｎｄ的一半，就ｃｗｎｄ值为１.重新进行慢开始算法。
  • 网络拥塞的处理方法：当网络出现超时时，无论在慢开始阶段还是拥塞避免阶段，都会直接把门阀置为当前窗口值的一半。这样做的目的就是减少主机发送的分组数，使得发生拥塞的路由器有足够时间，处理队列中积压的分组。

• 接收窗口与拥塞窗口的区别

  • 接收窗口：接收方根据目前接收缓存大小所允许发送方发送的最新窗口值，反应的是接收方的接收容量。TCP报文的首部窗口的字段通知发送方，接收窗口的大小。
  • 拥塞窗口：发送方根据自己估算的网络拥塞程度设置的窗口值。 反应网络中的容量。

• 快恢复

  • 发送方收到三个重复ACK时,执行"乘法减半"算法,将门阀设置为发送方的一半,并且将cwnd设置为改变后的门阀值大小,并且后续采用拥塞避免算法,每个传输伦茨,cwnd加一.

• 快重传

  • 当发送连续收到三个重复的ACk时,就直接重传对方尚未收到的报文段.而不必等待重传计时器的超时.

路由选择

• 路由器根据路由控制表转发数据包,将收到的数据包中目标主机IP与路由控制表比较来得出下一个路由器的接收.
• 静态路由,动态路由:
  • 静态路由:提前设置好,路由器和主机中并且路由信息固定.
    • 优点:简单,可靠,在负荷稳定,拓扑变化不大的网络中运行效果好. 安全适合较小的商业网络.
  • 动态路由:让路由协议在运行过程中,去自动地设置路由控制信息的一种方法.路由之间交换信息,按照一定的算法优化出来,获得最优的寻路效果.
    • 优点:改善网络的性能,有助于流量控制
    • 缺点:算法开销大,会增加网络负担,
• 动态路由算法:
  • 距离-向量算法:所有节点定期将整个路由表 选择性传给所有与之直接相邻的节点.
  • 链路状态路由算法:主动测试邻接点的状态,定期将路由状态传播给所有其他节点.

###　DNS　域名解析

• 为什么引入DNS
  • 计算机有其唯一的IP地址,通过IP地址找到对应的主机进行通信,但是IP地址太长,不易记住,所以引入了DNS（ＤＯｍain Name System）,在进行网络通信时,就使用主机名,而无需输入很长的IP地址. DNS有效的管理了 IP地址与主机命之间的对应关系.
• 域名:为了识别主机名称和组织机构的一种分层的的名称.(www.baidu.com);
• 域名服务器" 管理域名的主机和相应的软件,它可以管理所在分层的域的相关信息.
• DNS域名解析过程: 当接收到查询请求的域名服务器会在自己的数据库中查找,如果有就返回ip地址,如果没有则向上一层的根域名服务器进行查询处理.

什么是CDN?

• CDN加速意思就是在用户和我们的服务器之间加一个缓存机制，通过这个缓存机制动态获取IP地址根据地理位置，让用户到最近的服务器访问。
  那么CDN是个啥？
  全称Content Delivery Network即内容分发网络。

  CDN是一组分布在多个不同的地理位置的WEB服务器，用于更加有效的向用户发布内容，在优化性能时，会根据距离的远近来选择 。

  CDN系统能实时的根据网络流量和各节点的连接，负载状况及用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上，其目的是使用户能就近的获取请求数据，解决网络拥堵，提高访问速度，解决由于网络带宽小，用户访问量大，网点分布不均等原因导致的访问速度慢的问题。

  由于CDN部署在网络运营商的机房，这些运营商又是终端用户网络的提供商，因此用户请求的第一跳就到达CDN服务器，当CDN服务器中缓存有用户请求的数据时，就可以从CDN直接返回给浏览器，因此就可以提高访问速度。

  CDN能够缓存JavaScript脚本，css样式表，图片，图标，Flash等静态资源文件（不包括html页面），这些静态资源文件的访问频率很高，将其缓存在CDN可以极大地提高网站的访问速度，但由于CDN是部署在网络运营商的机房，所以在一般的网站很少用CDN加速。

  我们知道了什么是CDN，那么分发的原理是什么呢？

  1. 用户向浏览器提供需要访问的域名；
  2. 浏览器调用域名解析库对域名进行解析，由于CDN对域名解析过程进行了调整，所以解析函数库一般得到的是该域名对应的CNAME记录，为了得到实际的IP地址，浏览器需要再次对获得的CNAME域名进行解析以得到实际的IP地址；在此过程中，使用的全局负载均衡DNS解析。如根据地理位置信息解析对应的IP地址，使得用户能就近访问；
  3. 此次解析得到CDN缓存服务器的IP地址，浏览器在得到实际的ip地址之后，向缓存服务器发出访问请求；
  4. 缓存服务器根据浏览器提供的要访问的域名，通过Cache内部专用DNS解析得到此域名的实际IP地址，再由缓存服务器向此实际IP地址提交访问请求；
  5. 缓存服务器从实际IP地址得到内容以后，一方面在本地进行保存，以备以后使用，二方面把获取的数据放回给客户端，完成数据服务过程；
  6. 客户端得到由缓存服务器返回的数据以后显示出来并完成整个浏览的数据请求过程。

  下面我们来看一张图

  

  。

time_wait过多,以及如何优化

• 解决: 打开ＴＩＭＥＷＡＩＴ重用和回收.
  网络情况不好时，如果主动方无TIME_WAIT等待，关闭前个连接后，主动方与被动方又建立起新的TCP连接，这时被动方重传或延时过来的FIN包过来后会直接影响新的TCP连接；
  同样网络情况不好并且无TIME_WAIT等待，关闭连接后无新连接，当接收到被动方重传或延迟的FIN包后，会给被动方回一个RST包，可能会影响被动方其它的服务连接。
  过多的话会占用内存，一个TIME_WAIT占用4k大小
  解决方法
  相关参数优化调整（当然得根据服务器的实际情况配置，这里着重讲参数意义）：
  既然知道了TIME_WAIT的用意了，尽量按照TCP的协议规定来调整，对于tw的reuse、recycle其实是违反TCP协议规定的，服务器资源允许、负载不大的条件下，尽量不要打开，当出现TCP: time wait bucket table overflow，尽量调大下面参数：
  tcp_max_tw_buckets = 256000
  调整次参数的同时，要调整TIME_WAIT_2到TIME_WAIT的超时时间，默认是60s，优化到30s：
  net.ipv4.tcp_fin_timeout = 30
  其它TCP本身的配合参数类似与synack重传次数、syn重传次数等以后介绍，优化后也是有所益处的。

下面再说一下linux里TIME_WAIT专有的优化参数reuse、recycle，默认也都是关闭的，这两个参数必须在timestamps打开的前提下才能生效使用
1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_tw_reuse = 1
机器作为客户端时起作用，开启后time_wait在一秒内回收
net.ipv4.tcp_tw_recycle = 0 （不要开启，现在互联网NAT结构很多，可能直接无法三次握手）

开启后在3.5*RTO(RTO时间是根据RTT时间计算而来)内回收TIME_WAIT，并60s内同一源ip主机的socket
connect请求中的timestamp必须是递增的，对于服务端，同一个源ip可能会是NAT后很多机器，这些机器timestamp递增性无可保证，服务器会拒绝非递增请求连接，直接导致不能三次握手。

注意
tcp_tw_recycle：顾名思义就是回收TIME_WAIT连接。可以说这个内核参数已经变成了大众处理TIME_WAIT的万金油，如果你在网络上搜索TIME_WAIT的解决方案，十有八九会推荐设置它，不过这里隐藏着一个不易察觉的陷阱：

当多个客户端通过NAT方式联网并与服务端交互时，服务端看到的是同一个IP，也就是说对服务端而言这些客户端实际上等同于一个，可惜由于这些客户端的时间戳可能存在差异，于是乎从服务端的视角看，便可能出现时间戳错乱的现象，进而直接导致时间戳小的数据包被丢弃。参考：tcp_tw_recycle和tcp_timestamps导致connect失败问题。

tcp_tw_reuse：顾名思义就是复用TIME_WAIT连接。当创建新连接的时候，如果可能的话会考虑复用相应的TIME_WAIT连接。通常认为「tcp_tw_reuse」比「tcp_tw_recycle」安全一些，这是因为一来TIME_WAIT创建时间必须超过一秒才可能会被复用；二来只有连接的时间戳是递增的时候才会被复用。官方文档里是这样说的：如果从协议视角看它是安全的，那么就可以使用。这简直就是外交辞令啊！按我的看法，如果网络比较稳定，比如都是内网连接，那么就可以尝试使用。

不过需要注意的是在哪里使用，既然我们要复用连接，那么当然应该在连接的发起方使用，而不能在被连接方使用。举例来说：客户端向服务端发起HTTP请求，服务端响应后主动关闭连接，于是TIME_WAIT便留在了服务端，此类情况使用「tcp_tw_reuse」是无效的，因为服务端是被连接方，所以不存在复用连接一说。让我们延伸一点来看，比如说服务端是PHP，它查询另一个MySQL服务端，然后主动断开连接，于是TIME_WAIT就落在了PHP一侧，此类情况下使用「tcp_tw_reuse」是有效的，因为此时PHP相对于MySQL而言是客户端，它是连接的发起方，所以可以复用连接。

说明：如果使用tcp_tw_reuse，请激活tcp_timestamps，否则无效。
————————————————
版权声明：本文为CSDN博主「努力的土豆」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/twt936457991/article/details/90574284

粘包拆包问题:

• 参考:https://cloud.tencent.com/developer/article/1430021

cookie的原理,以及与session的区别

• cookie不属于http协议范围，由于http协议无法保持状态，但实际情况，我们却又需要“保持状态”，因此cookie就是在这样一个场景下诞生。
  cookie的工作原理是：由服务器产生内容，浏览器收到请求后保存在本地；当浏览器再次访问时，浏览器会自动带上cookie，这样服务器就能通过cookie的内容来判断这个是“谁”了。
  cookie虽然在一定程度上解决了“保持状态”的需求，但是由于cookie本身最大支持4096字节，以及cookie本身保存在客户端，可能被拦截或窃取，因此就需要有一种新的东西，它能支持更多的字节，并且他保存在服务器，有较高的安全性。这就是session。
  问题来了，基于http协议的无状态特征，服务器根本就不知道访问者是“谁”。那么上述的cookie就起到桥接的作用。
  我们可以给每个客户端的cookie分配一个唯一的id，这样用户在访问时，通过cookie，服务器就知道来的人是“谁”。然后我们再根据不同的cookie的id，在服务器上保存一段时间的私密资料，如“账号密码”等等。
  总结而言：cookie弥补了http无状态的不足，让服务器知道来的人是“谁”；但是cookie以文本的形式保存在本地，自身安全性较差；所以我们就通过cookie识别不同的用户，对应的在session里保存私密的信息以及超过4096字节的文本。
  另外，上述所说的cookie和session其实是共通性的东西，不限于语言和框架

session的原理

• cookie保存session的id：保存这个session id的方式可以采用cookie，一般这个cookie的名字都是类似于SEEESIONID。
• session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信
• 当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识如果已包含则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来\\使用（检索不到，会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送服务器。一般这个cookie的名字都是类似于SEEESIONID。但cookie可以被人为的禁止，则必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。

cookie 和session 的区别：

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

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

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

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

IP变化如何通知服务器

HTTP/HTTPS

• HTTPS 和 HTTP 的区别

  • htP（HyperText Transfer Protocol：超文本传输协议）是一种用于分布式、协作式和超媒体信息系统的应用层协议。 简单来说就是一种发布和接收 HTML 页面的方法，被用于在 Web 浏览器和网站服务器之间传递信息。

    HTTP 默认工作在 TCP 协议 80 端口，用户访问网站 http:// 打头的都是标准 HTTP 服务。

    HTTP 协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。

    HTTPS（Hypertext Transfer Protocol Secure：超文本传输安全协议）是一种透过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

    HTTPS 默认工作在 TCP 协议443端口，它的工作流程一般如以下方式：

    • 1、TCP 三次同步握手
    • 2、客户端验证服务器数字证书
    • 3、DH 算法协商对称加密算法的密钥、hash 算法的密钥
    • 4、SSL 安全加密隧道协商完成
    • 5、网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改。

    截至 2018 年 6 月，Alexa 排名前 100 万的网站中有 34.6% 使用 HTTPS 作为默认值，互联网 141387 个最受欢迎网站的 43.1% 具有安全实施的 HTTPS，以及 45% 的页面加载（透过Firefox纪录）使用HTTPS。2017 年3 月，中国注册域名总数的 0.11％使用 HTTPS。

    根据 Mozilla 统计，自 2017 年 1 月以来，超过一半的网站流量被加密。

    HTTP 与 HTTPS 区别

    • HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP） 数据传输过程是加密的，安全性较好。
    • 使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构） 申请证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
    • HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。
    • http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
    • HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。

• 拥塞控制和流量控制

  • 什么是流量控制？流量控制的目的？

    如果发送者发送数据过快，接收者来不及接收，那么就会有分组丢失。为了避免分组丢失，控制发送者的发送速度，使得接收者来得及接收，这就是流量控制。流量控制根本目的是防止分组丢失，它是构成TCP可靠性的一方面。

    如何实现流量控制？

    由滑动窗口协议（连续ARQ协议）实现。滑动窗口协议既保证了分组无差错、有序接收，也实现了流量控制。主要的方式就是接收方返回的 ACK 中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送。

    流量控制引发的死锁？怎么避免死锁的发生？

    当发送者收到了一个窗口为0的应答，发送者便停止发送，等待接收者的下一个应答。但是如果这个窗口不为0的应答在传输过程丢失，发送者一直等待下去，而接收者以为发送者已经收到该应答，等待接收新数据，这样双方就相互等待，从而产生死锁。
    为了避免流量控制引发的死锁，TCP使用了持续计时器。每当发送者收到一个零窗口的应答后就启动该计时器。时间一到便主动发送报文询问接收者的窗口大小。若接收者仍然返回零窗口，则重置该计时器继续等待；若窗口不为0，则表示应答报文丢失了，此时重置发送窗口后开始发送，这样就避免了死锁的产生。

    二：拥塞控制和流量控制的区别

    拥塞控制：拥塞控制是作用于网络的，它是防止过多的数据注入到网络中，避免出现网络负载过大的情况；常用的方法就是：（ 1 ）慢开始、拥塞避免（ 2 ）快重传、快恢复。

    流量控制：流量控制是作用于接收者的，它是控制发送者的发送速度从而使接收者来得及接收，防止分组丢失的。

输入网址到浏览器显示的过程.

全过程简要概述**
当我们将网址输入到浏览器后，第一件事就是解析 url 得到域名，通过 DNS 协议 获取到该域名的 ip 地址，得到 ip 后浏览器会先与服务器通过 TCP 三次握手建立连接，然后构建 HTTP 请求，将 HTTP 的传输工作交给操作系统的协议栈，发送请求成功后，浏览器会从服务端拿到该页面的 HTML 以及资源文件，浏览器会 渲染页面，呈现出我们所看到的模样。

在这整个过程中，涉及到了 DNS 解析，http请求，TCP\IP 协议栈、页面渲染等知识，当然也可以继续扩展，比如从 HTTP 可以说到 HTTPS，可以说到对称加密与非对称加密，可以说到网络安全等等，主要目的就是让整个面试过程跟着你的技术栈走，而不被面试官带到你不会的地方。

在这里我将重点写一下我在面试中喜欢拓展的方向，并拟出一份答案。

DNS 解析
浏览器在拿到 url 时，首先会对 url 进行解析，将域名与实际的文件路径分离，然后需要使用 DNS 协议，通过域名得到 IP 地址。

首先浏览器会查询浏览器缓存，如果有这个网址就可以直接获取到 IP，如果没有就进一步访问本机缓存，如果本机缓存也没有才会发起 DNS 请求。

而 DNS 的服务器是一个树状结构，对于域名来说是倒着进行解析的，根节点是根 DNS 服务器，他的子节点为 com、cn 这种顶级域 dns 服务器，然后进一步向下进行解析。

以 baidu.com 为例，当我们的电脑需要发起 DNS 请求的时候，会先对根 DNS 服务器发起请求，这个服务器的 IP 地址一般在每台电脑上都有，我们一般会设置为 8.8.8.8 或者 114.114.114.114，我们的电脑在访问根 DNS 服务器后，会得到 con 域 DNS 服务器的 IP，然后会继续访问 con 域 DNS 服务器，这时就能得到 baicu.com 的 IP 地址了。

HTTP 请求
在解析 url 时，我们能获取到需要请求资源的资源路径、端口号、请求参数等信息，这些信息会被存储在 http 头中，通过 DNS 请求获取到ip后，浏览器会构建并发送 HTTP 请求或者 HTTPS 请求，HTTPS 就是在 HTTP 的基础上加了一个 TLS 协议来进行数据加密，这个我们待会说。

HTTP 请求有很多种，但对资源的操作离不开增删改查，也就对应着 POST、DELETE、PUT、GET 请求。最常用的是 GET 和 POST，其区别在于 GET 的参数是在 url 中的，而 POST 的参数是在请求的 body 中。

以 GET 为例，当需要发送 HTTP 请求的时候，同样也不是直接就发送了，需要先查询浏览器缓存。浏览器中的缓存分为强缓存和协商缓存，浏览器发起 HTTP 请求时首先会根据 http 头信息来判断是存有强缓存，以及其是否过期，如果有强缓存且未过期则命中，不会发送请求到服务器了。如果强缓存没命中，则会向服务器发起请求，这个请求的 Header 头中会带有浏览器最后一次请求该资源的时间和一个资源校验码(使用资源修改时间、资源大小等信息生成)，服务器收到这个请求后会判断协商缓存是否过期，如果过期则返回新的资源信息，如果没过期则返回 304 状态码，表示资源未更新，可以使用缓存中的资源。

TCP->网络层连接

HTTP 请求发出后会将数据包交给下层协议栈处理，在传输层和网络层该数据包会被分别加上 TCP 头和 IP 头，并且被发送出去，沿路的网关会收到这个数据包并进行识别和转发，直到该数据包被服务器收到，通过相同的流程返回回复数据包。

页面渲染

一般来说，浏览器第一次从服务器请求的资源都是一个 HTML 文件，例如服务端默认的 index.html 等，浏览器获取到这个 HTML 文件就会对其进行解析，构建出一棵 DOM 树，并通过执行其中的 js 代码发起更多的请求，请求渲染页面需要的其他资源，CSS 或者一些外链的图片等，拿到 CSS 后将其与 DOM 树结合进行更进一步的渲染，我们就能看到页面了。

HTTPS
由于 HTTP 是使用信息明文传播，所以会有窃听、篡改、冒充等风险，所以 HTTPS 在 HTTP 的基础上加上了 SSL 层，通过加密的方式来保证数据安全。

SSL 通过加密防止窃听，通过签名来防止篡改，通过证书来防止冒充。
HTTPS 协议在客户端与服务端开始通信前，会进行密钥协商，通过一轮非对称加密，一般是RSA加密来传递后序通信过程使用的对称密钥，由于非对称加密较慢，后续通信过程中使用对称加密。在密钥协商的过程中，服务端会将自己的证书发送给客户端，客户端会到CA机构通过摘要值验证证书的合法性，从而防止中间人攻击。

补充提问：你对中间人攻击有哪些了解？
中间人攻击主要分为 SSL 劫持攻击、SSL 剥离攻击以及针对 SSL 算法的攻击

• SSL 劫持攻击即 SSL 证书欺骗攻击，攻击者为了获得HTTPS传输的明文数据，需要先将自己接入到客户端和目标网站之间；在传输过程中伪造服务器的证书，将服务器的公钥替换成自己的公钥，这样中间人就可以解密客户端和服务端的数据传输内容。可以通过在网站前端加入证书校验来预防 SSL 劫持攻击。
• SSL 剥离攻击，即将 HTTPS 连接降级到 HTTP 连接。假如客户端直接访问 HTTPS 的 URL，攻击者是没办法直接进行降级的，该攻击方式主要是利用用户并不会每次都直接在浏览器上输入 https 来访问网站或者有些网站并非全网 HTTPS，中间人攻击者在劫持了客户端与服务端的 HTTP 会话后，将 HTTP 页面里面所有的 https:// 超链接都换成 http:// ，用户在点击相应的链接时，是使用 HTTP 协议来进行访问。可以通过在网站前端检查 URL 是否被篡改来预防 SSL 剥离攻击。
  针对 SSL 算法的攻击：低版本的 SSL 协议是存在漏洞的，这些漏洞可能会被公共者利用，及时升级服务端的 SSL 配置可以预防针对 SSL 算法的攻击。
• 最终答案
  浏览器在拿到 url 时，首先会对 url 进行解析，将域名与实际的文件路径分离，然后需要使用 DNS 协议，通过域名得到 IP 地址。
  浏览器会查询浏览器缓存，如果有这个网址的缓存就可以直接获取到 IP，如果没有就进一步访问本机缓存，如果本机缓存也没有才会发起 DNS 请求。
  而 DNS 的服务器是一个树状结构，对于域名来说是倒着进行解析的，根节点是根 DNS 服务器，他的子节点为 com、cn 这种顶级域 dns 服务器，然后进一步向下进行解析。
  以 baidu.com 为例，当我们的电脑需要发起 DNS 请求的时候，会先对根 DNS 服务器发起请求，这个服务器的 IP 地址一般在每台电脑上都有，我们一般会设置为 8.8.8.8 或者 114.114.114.114，我们的电脑在访问根 DNS 服务器后，会得到 con 域 DNS 服务器的 IP，然后会继续访问 con 域 DNS 服务器，这时就能得到 baicu.com 的 IP 地址了。

得到 ip 后浏览器会先与服务器通过 TCP 三次握手建立连接，然后构建 HTTP 请求。
在解析 url 时，我们能获取到需要请求资源的资源路径、端口号、请求参数等信息，这些信息会被存储在 http 头中，通过 DNS 请求获取到 ip 后，浏览器会构建并发送 HTTP 请求或者 HTTPS 请求，HTTPS 就是在 HTTP 的基础上加了一个 TLS 协议来进行数据加密，这个我们待会说。
HTTP 请求有很多种，但对资源的操作离不开增删改查，也就对应着 POST、DELETE、PUT、GET 请求。最常用的是 GET 和 POST，其区别在于 GET 的参数是在 url 中的，而 POST 的参数是在请求的 body 中。
以 GET 为例，当需要发送 HTTP 请求的时候，同样也不是直接就发送了，需要先查询浏览器缓存。浏览器中的缓存分为强缓存和协商缓存，浏览器发起 HTTP 请求时首先会根据 http 头信息来判断是存有强缓存，以及其是否过期，如果有强缓存且未过期则命中，不会发送请求到服务器了。如果强缓存没命中，则会向服务器发起请求，这个请求的 Header 头中会带有浏览器最后一次请求该资源的时间和一个资源校验码(使用资源修改时间、资源大小等信息生成)，服务器收到这个请求后会判断协商缓存是否过期，如果过期则返回新的资源信息，如果没过期则返回 304 状态码，表示资源未更新，可以使用缓存中的资源。

HTTP 请求发出后会将数据包交给下层协议栈处理，在传输层和网络层该数据包会被分别加上 TCP 头和 IP 头，并且被发送出去，沿路的网关会收到这个数据包并进行识别和转发，直到该数据包被服务器收到，通过相同的流程返回回复数据包。

一般来说，浏览器第一次从服务器请求的资源都是一个 HTML 文件，例如服务端默认的 index.html 等，浏览器获取到这个 HTML 文件就会对其进行解析，构建出一棵DOM树，并通过执行其中的 js 代码发起更多的请求，请求渲染页面需要的其他资源，CSS 或者一些外链的图片等，拿到 CSS 后将其与 DOM 树结合进行更进一步的渲染，我们就能看到页面了。

最后再补充一下 HTTPS，由于 HTTP 是使用信息明文传播，所以会有窃听、篡改、冒充等风险，所以 HTTPS 在 HTTP 的基础上加上了 SSL 层，通过加密的方式来保证数据安全。
SSL 通过加密防止窃听，通过签名来防止篡改，通过证书来防止冒充。
HTTPS 协议在客户端与服务端开始通信前，会进行密钥协商，通过一轮非对称加密，一般是RSA加密来传递后序通信过程使用的对称密钥，由于非对称加密较慢，后续通信过程中使用对称加密。在密钥协商的过程中，服务端会将自己的证书发送给客户端，客户端会到 CA 机构通过摘要值验证证书的合法性，从而防止中间人攻击。

作者：weak chicken
链接：https://leetcode-cn.com/circle/discuss/UrcaDQ/
来源：力扣（LeetCode）
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

ip变化时,如何通知DNS

6.3 TCP/IP

• TCP、UDP属于哪个层：传输层
• TCP 如何保证可靠传输的
  • 校验和,序列号,确认应答,流量控制,超时重传.
• tcp 连接过程中 syn_sent 连接数过多会是什么原因造成的
  • 你很有可能中了蠕虫病毒.这类病毒为了感染别的计算机，它就要扫描别的计算机，在扫描的过程中对每个要扫描的计算机都要发出了同步请求，这也是出现许多SYN_SENT的原因

6.4 三次握手与四次握手

• TCP 三次握手四次挥手工作在哪一层？

  TCP 三次握手的主要目的是防止失效的连接请求报文被服务端接受

  如果只有两次握手，假设当客户端发送第一次连接请求由于网络拥塞的原因，迟迟未到服务端，客户端没接收到确认报文，认为服务端没有收到，于是重新发送请求报文并与服务端建立连接，等这次连接断开了，之前滞留的那个请求报文又到达了服务端，就会让服务端与客户端再次连接成功，这时服务端就会一直等待客户端发送请求，造成了资源的浪费。

  两次握手只能保证单向链路是可以通信的，理论上来说，要保证双向链路可以通信需要四次握手，但实际上服务端给客户端的 SYN 和 ACK 数据包可以合为一次握手，所以实际上只需要三次握手即可。

  -　加问：那挥手为什么需要四次呢？三次不行吗？
  答：挥手阶段中服务端的 ACK 和 FIN 数据包不能合为一次。因为挥手阶段的流程为客户端发送FIN数据包表示自己发完了，服务端立即回复 ACK 数据包表示自己知道了，此时客户端到服务端的连接已经释放了，客户端不会再发送数据了，但服务端还可以继续向客户端发送数据，等到服务端也完成了数据发送，才会发送 FIN，这时客户端回复 ACK，就可以结束通信了。
  -　加问：TCP 在四次挥手的过程中为什么客户端最后还要等待 2MSL(Maximum Segment Lifetime)？
  答：因为客户端要保证他的 ACK 包顺利到达服务端，如果客户端的ACK数据包丢失，则服务端或重新发送 FIN 包到客户端，而这两个过程的最长时间为 1MSL，加起来为 2MSL，如果 2MSL 后客户端还没有收到服务端重发的 FIN 包，则说明 ACK 包顺利到达，可以关闭连接了。
  -　TCP 在握手阶段怎么管理客户端的连接？
  TCP 在握手阶段服务端维护了两个队列：半连接队列和全连接队列

  在客户端发起第一次握手时，服务端会把此请求放入半连接队列，并回复 SYN+ACK
  在客户端回复 ACK，也就是第三次握手时，服务端将此连接加入到全连接队列
  如果全连接队列满，则服务端的处理方式和 tcp_abort_on_overflow 参数的设置有关，如果该参数为 0，则丢弃该 ACK，如果为 1 则发送 RST 到客户端，直接放弃此次连接。
  此条是我在了解DDOS时发现的，并非常考点，SYN Flood 攻击时会造成服务端的半连接队列被占满，从而影响到服务。

  TCP 通过哪些方式来保证数据的可靠性？
  TCP 保证数据可靠性的方式大致可以分为三类：

  在数据包层面：校验和
  在数据包传输层面：序列号、确认应答、超时重传
  在流量控制层面：拥塞控制
  校验和
  计算方式：在数据传输的过程中，将发送的数据段都当做一个 16 位的整数。将这些整数加起来。并且加上进位，最后取反，得到校验和。
  TCP 与 UDP 校验方式相同

  序列号、确认应答、超时重传
  在数据包传输的过程中，每个数据包都有一个序列号，当数据到达接收方时，接收方会发出一个确认应答，表示收到该数据包，并会说明下一次需要接收到的数据包序列号(32 位确认序列号)。如果发送端在一段时间内(2RTT 没有收到确认应答，则说明可能是发送的数据包丢失或者确认应答包丢失，此时发送端会进行数据包重传。

  但发送端并不是一定要等到接收到上一个数据包的确认应答再发送下一个数据包，TCP 会利用窗口控制来提高传输速度，在一个发送窗口大小内，不用一定要等到应答才能发送下一段数据，发送窗口大小就是无需等待确认而可以继续发送数据的最大值。而发送窗口的大小是由接收端的接受窗口的剩余大小和拥塞窗口来决定的。(TCP 会话的双方都各自维护一个发送窗口和一个接收窗口)

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

  TCP 的拥塞控制主要是采用慢启动以及增性加，乘性减的机制，TCP一开始将拥塞窗口设置的很小，在逐渐经过一段时间的指数增长后超过门限，进入增性加阶段，此时窗口大小的增长是线性的，比之前的指数增长要慢很多，而当发生网络拥塞时，拥塞窗口大小直接减半（乘性减）。

  TCP 长连接和短连接有什么区别？
  TCP 短连接是指客户端与服务端连接后只进行一次读写就关闭连接，一般是客户端关闭。
  而长连接则是指在进行完一次读写后不关闭连接，直到服务端压力过大则选择关闭一些长时间为进行读写的连接。

  TCP 短连接的优点在于管理简单，而且不会对服务端造成太大的压力，而缺点是每次读写都需要连接耗时较长。

  TCP 长连接的优点是可以迅速进行多次读写，缺点是对服务端压力大，且容易被恶意连接影响服务。

  长短连接的区别就在于客户端和服务端选择的关闭策略不同，具体需要根据应用场景来选择合适的策略。

  TCP 粘包、拆包及解决方法？
  TCP 之所以会产生粘包和拆包拆包问题，是因为他本身就是一种字节流协议，TCP 本身就没有数据包的概念，需要发送和接受的数据是没有格式的，以字节流的形式传输，而在传输过程中会被分割为一段段数据块，也就是报文。TCP 要发送的数据会被先放置在数据缓冲区，接收数据也是从缓冲区获取，而缓冲区的大小即为最大报文长度，如果需要发送的数据长度大于缓冲区剩余的大小或者大于最大报文长度，则会出现拆包，如果是需要发送的数据很少，而短时间内又有其他数据包需要发送，就会出现粘包的现象。

  解决方案有很多种，可以在数据包头加上数据包长度，或者把每个数据包封装为固定长度，不够则补 0，以及可以使用特定分割符号等等

  我们在项目中也遇到过这种问题，因为我们在做流量检测的时候，有时候难以找到恶意软件的流量特征，会把数据包长度当做特征来使用，有些恶意软件内部无论会把这些数据包长度写死，这样恶意软件本身就不存在有无法解析粘包和拆包的情况，但对于我们来说，检测就会遇到障碍，尤其是攻击者可以设置 MSS 来使得数据包长度改变，对于这种攻击我们目前也没有很好的方案来解决。。

GET与POST以及幂等性

• GET 和 POST 方法都是基于 TCP/IP 协议，也就是说，两者的数据传输都是建立在 TCP 的连接，所以，如果从两者的本质来讲并没有多大的区别，你非要给 GET 方法加上 request body，给 POST 方法加上 URL 参数都是行得通的，HTTP 协议对于 GET 和 POST 其实并没有长度限制。

  因而，两者的区别更多地体现在使用规范上，从使用规范上来说：

  GET方法从服务器获取资源，POST是想服务器发送数据
  GET 浏览器回退是无害的，而 POST 会再次提交请求。
  GET 产生的 URL 地址可以被书签收藏，并且被浏览器缓存，而 POST 不能书签收藏也不能缓存。
  GET 只能进行 URL 编码，而 POST 支持多种编码方式。
  GET 参数通过 URL 传递，并且长度有限制，而 POST 放在 request body 并且长度没有限制。并且，正因为这个原因， GET 比 POST 更不安全，因为参数暴露在 URL 中。
  二者还有一个显著区别：GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包。

  对于 GET 方式的请求，浏览器会把 http header 和 data 一并发送出去，服务器响应 200（返回数据）；

  而对于 POST，浏览器先发送 header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 ok（返回数据）。

• 什么是幂等性?

  • 一次和多次请求一个资源应该具有同样的副作用.

• 如何避免post的重复提交?

  • 自定义注解+AOP:我们将ip+接口地址作为key，随机生成UUID作为value，存入redis。每次请求进来，根据key查询redis，如果存在则说明是重复提交，抛出异常，如果不存在，则是正常提交，将key存入redis。