网络模型
OSI七层网络模型
应用层
协议有：HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP
表示层
数据的表示、安全、压缩。格式有，JPEG、ASCll、DECOIC、加密格式等
会话层
建立、管理、终止会话。对应主机进程，指本地主机与远程主机正在进行的会话
传输层
定义传输数据的协议端口号，以及流控和差错校验。协议有：TCP UDP，数据包一旦离开网卡即进入网络传输层
网络层
进行逻辑地址寻址，实现不同网络之间的路径选择。协议有：ICMP IGMP IP（IPV4 IPV6） ARP RARP
DNS服务器
DNS服务器器负责解析域名，然后返回这个域名对应的IP给我们。
数据链路层
建立逻辑连接、进行硬件地址寻址、差错校验等功能。将比特组合成字节进而组合成帧，用MAC地址访问介质，错误发现但不能纠正。
- 以太⽹网协议
以太⽹网协议规定，⼀一组电信号构成⼀一个数据包，我们把这个数据包称之为帧。每⼀一个桢由标头(Head)和数据(Data)两部分组成。 - MAC 地址
计算机之间的数据传送，就是通过 MAC 地址来唯⼀一寻找、传送的。 - 广播与ARP协议
物理层
建立、维护、断开物理连接。
物理理层负责把两台计算机连起来，然后在计算机之间通过⾼高低电频来传送0,1这样的电信号。
七层模型传输数据过程：
TCP 三次握手
建立连接前服务端需要监听端口，所以初始状态是LISTEN。
- 客户端建立连接，发送一个SYN同步包，发送之后状态变成SYN_SENT
- 服务端收到SYN之后，同意建立连接，返回一个ACK响应，同时也会给客户发送一个SYN包，发送完成之后状态变为SYN_RCVD
- 客户端收到服务端的ACK之后，状态变为ESTABLISHED，返回ACK给服务端。服务端收到之后状态也变为ESTABLISHED，连接建立完成。
客户端的初始化序列号 ISN
为什么是三次握手？不是两次、四次？
1.防止已过期的连接请求报文突然又传送到服务器，因而产生错误
2.确认双方的接受能力、发送能力是否正常。
3.指定⾃己的初始化序列号，为后面的可靠传送做准备。
三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。
什么是 SYN 攻击？如何避免 SYN 攻击？
我们都知道 TCP 连接建立是需要三次握手，假设攻击者短时间伪造不同 IP 地址的 SYN 报文，服务端每接收到一个 SYN 报文，就进入SYN_RCVD 状态，但服务端发送出去的 ACK + SYN 报文，无法得到未知 IP 主机的 ACK 应答，久而久之就会占满服务端的 SYN 接收队列（未连接队列），使得服务器不能为正常用户服务。
1.修改 Linux 内核参数
其中一种解决方式是通过修改 Linux 内核参数，控制队列大小和当队列满时应做什么处理。
当网卡接收数据包的速度大于内核处理的速度时，会有一个队列保存这些数据包。控制该队列的最大值如下参数：
net.core.netdev_max_backlog
SYN_RCVD 状态连接的最大个数：
net.ipv4.tcp_max_syn_backlog
超出处理能时，对新的 SYN 直接回 RST，丢弃连接：
net.ipv4.tcp_abort_on_overflow
2.tcp_syncookies
tcp_syncookies 的方式可以应对 SYN 攻击的方法：
net.ipv4.tcp_syncookies = 1
当 「 SYN 队列」满之后，后续服务器收到 SYN 包，不进入「 SYN 队列」；
计算出一个 cookie 值，再以 SYN + ACK 中的「序列号」返回客户端，
服务端接收到客户端的应答报文时，服务器会检查这个 ACK 包的合法性。如果合法，直接放入到「 Accept 队列」。
最后应用通过调用 accpet() socket 接口，从「 Accept 队列」取出的连接。
四次挥手的过程
- 客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入FIN_WAIT_1 状态。
- 服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。
- 客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。
- 等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。
- 客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态
- 服务器收到了 ACK 应答报文后，就进入了 CLOSE 状态，至此服务端已经完成连接的关闭。
- 客户端在经过 2MSL 一段时间后，自动进入 CLOSE 状态，至此客户端也完成连接的关闭。
为什么挥手需要四次？
再来回顾下四次挥手双方发 FIN 包的过程，就能理解为什么需要四次了。
- 关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
- 服务器收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN报文给客户端来表示同意现在关闭连接。
为什么 TIME_WAIT 等待的时间是 2MSL？
网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。
为了保证连接的可靠关闭。如果server没有收到最后一个ACK，那么就会重发FIN。
为了避免端口重用带来的数据混淆。如果client直接进入CLOSED状态，又用相同端口号向server建立一个连接，上一次连接的部分数据在网络中延迟到达server，数据就可能发生混淆了。
TCP怎么保证传输过程的可靠性？
- 合理的数据大小：TCP 发送的数据并不是固定的大小，而是会根据实际情况调整报文段的大小。
- 检验和：发送端按照特定算法计算出 TCP 报文段的检验和并存储在 TCP
首部中的对应字段上，接收端在接收时会以同样的方式计算校验和，如果不一致，说明报文段出现错误，会将其丢弃。 - 序号与确认序号：对乱序的数据进行排序后发给应用层，并丢弃重复的数据。
- 超时重传机制：当 TCP发出一个报文段后，它会启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段，后面会细讲这个机制。
- 连接管理：也就是三次握手和四次挥手，连接的可靠性是整体可靠性的前提，本文第二部分将会详细介绍连接管理的内容。
- 流量控制：TCP 双方都有固定大小的缓冲区，流量控制的原理是利用滑动窗口控制数据发送速度，避免缓冲区溢出导致数据丢失。
- 拥塞控制：TCP 利用慢启动和拥塞避免等算法实现了拥塞控制。
TCP 的流量控制与滑动窗口
什么是流量控制？
TCP 连接双方的主机都为该连接设置了发送缓存和接收缓存，这些缓存起到了蓄水池的作用，我们肯定不能把上层应用程序发来的数据一股脑儿发送到网络中，而是利用发送缓存将其缓存起来，然后再按一定的速率通过网络发送给对方，而接收缓存的作用是把对方传来的数据先缓存起来，等到己方应用程序有空的时候再来取走数据。
早期的流量控制模式——停止-等待模式 (stop-wait)
顾名思义就是发送方在发送一个数据包后就停止发送，等待对方响应 ACK，然后才能继续发送数据。
滑动窗口
我们可以把发送方的发送缓存中的字节分为以下四类，每个编号对应一个字节：
发送缓存中的字节分类
- 第一类：已发送且已确认，这些数据已经发送成功并已经被确认的数据，比如图中的前31个bytes，这些数据其实的位置是在窗口之外了，下一步将被移出发送缓存。窗口内顺序最低的字节被确认之后，窗口左边界会向右移动，称为窗口合拢。
- 第二类：已发送但未收到确认，这部分数据已经被发送出去，但是还没有收到接收端的 ACK，认为并没有完成发送，这部分数据属于窗口内的数据。
- 第三类：未发送但是接收方已经准备好接收，这部分是尽快发送的数据，这部分数据已经被加载到缓存中，也在发送窗口中，正在等待发送，其实这个窗口是完全有接收方告知的，接收方告知当前可以接受这些数据，所以发送方需要尽快的发送。
- 第四类：未发送且接收方未准备好接收，这些数据属于未发送，同时接收端也不允许发送的，因为这些数据已经超出了发送端所接收的范围。
发送窗口和接收窗口
滑动窗口的动态效果:
TCP 的拥塞控制
什么是拥塞控制
当数据从一个大的管道 (比如一个快速局域网)向一个较小的管道 (比如较慢的广域网)发送的时候就会发生拥塞，还有一种情况就是当多个输入流到达一个路由器，而路由器的输出流小于这些输入流的总和时，也会发生拥塞。
如何实现拥塞控制？
TCP 一共使用了四种算法来实现拥塞控制：1、慢开始 (slow-start)；2、拥塞避免 (congestion avoidance)；3、快速重传 (fast retransmit)；4、快速恢复 (fast recovery)。
慢开始
就是不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大 逐渐增加拥塞窗口的大小。
为了防止 cwnd 增长过大引起网络拥塞，设置一个慢开始门限(slow start threshold，简写为 ssthresh)，初始值为16 ，
当cnwd < ssthresh，使用慢开始算法
当 cnwd = ssthresh，既可使用慢开始算法，也可以使用拥塞避免算法
当 cnwd > ssthresh，使用拥塞避免算法
拥塞避免
让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口加一。
快速重传
快速重传要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)，而不要等到自己发送数据时捎带确认。
快速恢复
当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把 ssthresh 门限减半。 但是接下去并不执行慢开始算法。考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将 cwnd 设置为 ssthresh 的大小， 然后执行拥塞避免算法。
TCP 粘包与拆包
我们知道 TCP 是以字节流的方式传输数据，传输的最小单位为一个报文段（segment）。TCP 首部 中有个选项 (Options)的字段，常见的选项为 MSS (Maximum Segment Size最大消息长度)，它是收发双方协商通信时每一个报文段所能承载的最大有效数据的长度。数据链路层每次传输的数据有个最大限制MTU (Maximum Transmission Unit)，一般是1500字节，超过这个量要分成多个报文段，MSS 则是这个最大限制减去 TCP 的首部，光是要传输的数据的大小，一般为1460字节。
MSS = MTU - Header
TCP 为提高性能，发送端会将需要发送的数据发送到发送缓存，等待缓存满了之后，再将缓存中的数据发送到接收方。同理，接收方也有接收缓存这样的机制，来接收数据。
上面这些是发生 TCP 粘包和拆包的前提，下面是具体的原因：
- 要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包。
- 待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。
- 应用程序写入数据小于剩余缓存大小，网卡将应用多次写入的数据先缓存起来，然后一起发送到网络上，这将会发生粘包。
- 接收数据端的应用层没有及时读取接收缓存中的数据，将发生粘包。
TCP 粘包和拆包的解决方案
-
设置定长消息，服务端每次读取既定长度的内容作为一条完整消息。
-
设置消息边界，数据结尾尾增加特殊字符分割。
-
使用带消息头的协议，消息头存储消息开始标识及消息长度信息，接收方获取消息头的时候解析出消息长度，然后向后读取该长度的内容。
浏览器请求一个网址的过程？
- 首先通过DNS服务器把域名解析成IP地址，通过IP和子网掩码判断是否属于同一个子网
- 构造应用层请求http报文，传输层添加TCP/UDP头部，网络层添加IP头部，数据链路层添加以太网协议头部
- 数据经过路由器、交换机转发，最终达到目标服务器，目标服务器同样解析数据，最终拿到http报文，按照对应的程序的逻辑响应回去。
HTTP 和 HTTPS 的区别
HTTP
是一种 超文本传输协议(Hypertext Transfer Protocol)，HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。
HTTP 主要内容分为三部分，超文本（Hypertext）、传输（Transfer）、协议（Protocol）。
- 超文本就是不单单只是本文，它还可以传输图片、音频、视频，甚至点击文字或图片能够进行超链接的跳转。
- 上面这些概念可以统称为数据，传输就是数据需要经过一系列的物理介质从一个端系统传送到另外一个端系统的过程。通常我们把传输数据包的一方称为请求方，把接到二进制数据包的一方称为应答方。
- 而协议指的就是是网络中(包括互联网)传递、管理信息的一些规范。如同人与人之间相互交流是需要遵循一定的规矩一样，计算机之间的相互通信需要共同遵守一定的规则，这些规则就称为协议，只不过是网络协议。
HTTP1.0/1.1/2.0
HTTP 1.1
- HTTP 1.1 使用了摘要算法来进行身份验证
- HTTP 1.1默认使用长连接，长连接就是只需一次建立就可以传输多次数据，传输完成后，只需要一次切断连接即可。长连接的连接时长可以通过请求头中的 keep-alive 来设置
- HTTP 1.1 中新增加了 E-tag，If-Unmodified-Since, If-Match, If-None-Match等缓存控制标头来控制缓存失效。
- HTTP 1.1 支持断点续传，通过使用请求头中的 Range 来实现。
- HTTP 1.1 使用了虚拟网络，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web
Servers），并且它们共享一个IP地址。
HTTP 2.0
HTTP 2.0 是 2015 年开发出来的标准，它主要做的改变如下
- 头部压缩，由于 HTTP 1.1 经常会出现 User-Agent、Cookie、Accept、Server、Range
等字段可能会占用几百甚至几千字节，而 Body 却经常只有几十字节，所以导致头部偏重。HTTP 2.0 使用 HPACK 算法进行压缩。 - 二进制格式，HTTP 2.0 使用了更加靠近 TCP/IP 的二进制格式，而抛弃了 ASCII 码，提升了解析效率
- 强化安全，由于安全已经成为重中之重，所以 HTTP2.0 一般都跑在 HTTPS 上。
- 多路复用，即每一个请求都是是用作连接共享。一个请求对应一个id，这样一个连接上可以有多个请求。
HTTPS
HTTPS实现原理
HTTPS其实就是将HTTP的数据包再通过SSL/TLS加密后传输，那么SSL/TLS又是什么呢？
- 用户通过浏览器请求https网站，服务器收到请求，选择浏览器支持的加密和hash算法，同时返回数字证书给浏览器，包含颁发机构、网址、公钥、证书有效期等信息。
- 浏览器对证书的内容进行校验，如果有问题，则会有一个提示警告。否则，就生成一个随机数X，同时使用证书中的公钥进行加密，并且发送给服务器。
- 服务器收到之后，使用私钥解密，得到随机数X，然后使用X对网页内容进行加密，返回给浏览器
- 浏览器则使用X和之前约定的加密算法进行解密，得到最终的网页内容。
- 后续HTTPS请求使用之前交换好的随机Key进行对称加解密。
对称加密与非对称加密
对称加密是指有一个密钥，用它可以对一段明文加密，加密之后也只能用这个密钥来解密得到明文。
然而，在HTTPS的传输场景下，服务端事先并不知道客户端是谁，你也不可能在事先不通过互联网和每一个网站的管理员都悄悄商量好一个通信密钥出来，那么必然存在一个密钥在互联网上传输的过程，如果在传输过程中被别人监听到了，那么后续的所有加密都是无用功。
最主要的原因是非对称加解密耗时要远大于对称加解密，对性能有很大损耗，大家的使用体验很差。
所以，我们才最终选用了上文介绍到非对称加密+对称加密的方案
- 服务端有非对称加密的公钥A1，私钥A2；
- 客户端发起请求，服务端将公钥A1返回给客户端；
- 客户端随机生成一个对称加密的密钥K，用公钥A1加密后发送给服务端；
- 服务端收到密文后用自己的私钥A2解密，得到对称密钥K，此时完成了安全的对称密钥交换，解决了对称加密时密钥传输被人窃取的问题
- 之后双方通信都使用密钥K进行对称加解密。
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
