目录
分层模型
Mac层定义了本地局域网的传输行为,IP层定义了整个网络端到端的传输行为,网络传输以包为单位,二层叫帧,网络层叫包,传输层叫段,笼统称为包;包单独传输,自行选路,在不同设备封装解封装,不保证到达,udp完全继承这些特性
osi参考模型七层
1.应用层 所有能产生网络流量的程序
2.表示层 在传输之前是否进行加密或压缩处理 二进制 ascil
3.会话层
windows查看会话命令netstat -n
查具体的netstat -nb
ESTABLISHED已经建立的会话
TIME_WAIT这个会话快释放了
4.传输层 可靠传输,流量控制,不可靠传输
将数据分段,编号
5.网络层 负责选择最佳路径 规划IP地址
负责写IP地址,从哪儿传到那儿
6.数据链路层 帧的开始和结束,透明传输,差错校验,纠错在传输层
负责写Mac地址,从哪儿转到那儿
7.物理层 接口标准 电器标准 如何在物理链路上传输更快的速度
传输层
所谓的建立连接,是为了在客户端和服务端维护连接,而建立一定的数据结构来维护双方交互的状态,用这样的数据结构来保证所谓的面向连接的特性
1.TCP和UDP有哪些区别
1.TCP提供可靠交付,无差错,不丢失,不重复且按序到达;UDP继承了IP包的特性,不保证不丢失,不保证按序到达
2.TCP是面向字节流的;UDP继承了IP包的特性,基于数据报的,一个一个的发,一个一个的收
3.TCP是可以有拥塞控制的.会根据网络情况调整自己的行为,如调节速度;udp就不会,该发就发,也不管网络状态
4.TCP是一个有状态服务(精确的记着发了没有,接受没有,应该收那个).UDP则是无状态的
2.UDP
UDP包头
UDP的三大特点
1.沟通简单,没有大量的数据结构,处理逻辑,报头字段等
2.不会建立连接,虽然有端口号,但是谁都可以给他发送数据,也可以发送数据给任何人
3.即使网络拥塞,也不会拥塞控制
不保证不丢失，不保证按顺序到达。
UDP的三大使用场景
1.需要资源少,情况比较好的内网,或者对于丢包不敏感的应用
2.不需要一对一的沟通,建立连接,而是可以广播的应用
3.需要处理速度快,时延低,可以容忍少数丢包,但是要求即便网络拥塞,也好不退缩,一往无前的时候
基于UDP的5个例子
1.网页或者APP的访问
2.流媒体的协议
3.实时游戏
4.IOT物联网
5.移动通信领域
3.TCP
TCP特点
面向连接：三次握手之后,双方开辟资源,带来了连接
所谓的建立连接，是为了在客户端和服务端维护连接，而建立一定的数据结构来维护双方交互的状态，用这样的数据结构来保证所谓的面向连接的特性。
可靠传输：确认机制保证了可靠传输
TCP 包头格式
1.tcp状态位:syn发起一个连接,ack是回复,rst是重新连接,fin是结束连接
2.tcp的三次握手(四层内核完成的):请求->应答->应答之应答
3.数据传输是七层应用完成的
三次握手
三次握手主要解决建立连接和TCP 包的序号的问题
一开始，客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端口，处于 LISTEN 状态。然后客户端主动发起连接 SYN，之后处于 SYN-SENT 状态。服务端收到发起的连接，返回 SYN，并且 ACK 客户端的 SYN，之后处于 SYN-RCVD 状态。客户端收到服务端发送的 SYN 和 ACK 之后，发送 ACK 的 ACK，之后处于 ESTABLISHED 状态，因为它一发一收成功了。服务端收到 ACK 的 ACK 之后，处于 ESTABLISHED 状态，因为它也一发一收了。
四次挥手
等待的时间设为 2MSL，MSL 是 Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃
还有一个异常情况就是，B 超过了 2MSL 的时间，依然没有收到它发的 FIN 的 ACK，怎么办呢？按照 TCP 的原理，B 当然还会重发 FIN，这个时候 A 再收到这个包之后，A 就表示，我已经在这里等了这么长时间了，已经仁至义尽了，之后的我就都不认了，于是就直接发送 RST，B 就知道 A 早就跑了。
socket(IP+port->IP+port)套接字
TCP顺序和丢包问题、流量控制、拥塞控制
- 累计确认或累计应答:
为了保证不丢包，对于发送的包都要进行应答，但是这个应答也不是一个一个来的，而是会应答某个之前的 ID，表示都收到了，这种模式称为累计确认或者累计应答（cumulative acknowledgment）。
- 滑动窗口
发送端缓存:1.发送已确认2.发送未确认3.等待发送4.暂不发送
在 TCP 里，接收端会给发送端报一个窗口的大小，叫 Advertised window。这个窗口的大小应该等于上面的第二部分加上第三部分
接收端缓存:1.接收已确认2.马上接收3.没法接收
窗口大小Advertised window为第二部分长度
- 顺序问题与丢包问题
确认与重发的机制
超时重试：发送端对每一个发送了，但是没有 ACK 的包，都有设一个定时器，超过了一定的时间，就重新尝试。这个超时时间为RTT
自适应重传算法：超时间隔加倍。每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍。两次超时，就说明网络环境差，不宜频繁反复发送。
快速重传的机制：当接收方收到一个序号大于下一个所期望的报文段时，就会检测到数据流中的一个间隔，于是它就会发送冗余的 ACK，仍然 ACK 的是期望接收的报文段。而当客户端收到三个冗余的 ACK 后，就会在定时器过期之前，重传丢失的报文段。
还有一种方式称为 Selective Acknowledgment （SACK）。这种方式需要在 TCP 头里加一个 SACK 的东西，可以将缓存的地图发送给发送方。例如可以发送 ACK6、SACK8、SACK9，有了地图，发送方一下子就能看出来是 7 丢了。
- 流量控制问题
对于包的确认中，同时会携带一个窗口的大小。
通过修改滑动窗口的大小来实现流量控制
- 拥塞控制问题
拥塞控制的问题，也是通过窗口的大小来控制的，前面的滑动窗口 rwnd 是怕发送方把接收方缓存塞满，而拥塞窗口 cwnd，是怕把网络塞满。
TCP 的拥塞控制主要来避免两种现象，包丢失和超时重传。一旦出现了这些现象就说明，发送速度太快了
拥塞窗口和滑动窗口共同控制发送速度,为了避免包丢失和超时重传
拥塞窗口的慢启动
一条 TCP 连接开始，cwnd 设置为一个报文段，一次只能发送一个；当收到这一个确认的时候，cwnd 加一，于是一次能够发送两个；当这两个的确认到来的时候，每个确认 cwnd 加一，两个确认 cwnd 加二，于是一次能够发送四个；当这四个的确认到来的时候，每个确认 cwnd 加一，四个确认 cwnd 加四，于是一次能够发送八个。可以看出这是指数性的增长。
当窗口大小超过慢启动阈值65535时，就需要减小窗口增大的速度了
每收到一个确认后，cwnd 增加 1/cwnd，我们接着上面的过程来，一次发送八个，当八个确认到来的时候，每个确认增加 1/8，八个确认一共 cwnd 增加 1，于是一次能够发送九个，变成了线性增长。
当出现了拥塞，也即出现了丢包，需要超时重传
cwnd 减半为 cwnd/2（传统方式重置为1），然后 sshthresh = cwnd，当三个包返回的时候，cwnd = sshthresh + 3，也就是没有一夜回到解放前，而是还在比较高的值，呈线性增长。
应用层
HTTP协议
1.http1.1:是基于TCP的协议
1.什么是协议:计算机与网络设备用进行通信,双方要基于相同的方法,不同的硬件,操作系统之间的通信,也要基于相同的方法和规则
1.双方的2.一致的
2.URI和URL
1.URL——统一资源定位符 是先诞生的,表示互联网中资源的地址
URL，叫作统一资源定位符。之所以叫统一，是因为它是有格式的。HTTP 称为协议，www.163.com 是一个域名，表示互联网上的一个位置。有的 URL 会有更详细的位置标识，例如 http://www.163.com/index.html 。正是因为这个东西是统一的，所以当你把这样一个字符串输入到浏览器的框里的时候，浏览器才知道如何进行统一处理。
2.URN表示资源独一无二的名称
3.URI 统一资源标识符（Uniform Resource Identifier）。因为它经常出现在浏览器的地址栏里，所以俗称为“网络地址”，简称“网址”。
3.HTTP请求的构建
第一部分是请求行，第二部分是请求的首部字段，第三部分才是请求的正文实体。
请求行:描述了客户端想要如何操作服务器端的资源
请求方法：是一个动词，如 GET, POST, PUT, DELETE,表示对资源的操作；
请求目标：通常是一个 URI，标记了请求方法要操作的资源；
版本号：表示报文使用的 HTTP 协议版本。
首部字段
首部字段是key value ,通过冒号分隔
1. Accept-Charset: 表示客户端可以接受的字符集
2. Content-Type: 正文的格式(如json)
3. Cache-control 是用来控制缓存的。当客户端发送的请求中包含 max-age 指令时，如果判定缓存层中，资源的缓存时间数值比指定时间的数值小，那么客户端可以接受缓存的资源；当指定 max-age 值为 0，那么缓存层通常需要将请求转发给应用集群。
4. If-Modified-Since 也是一个关于缓存的。也就是说，如果服务器的资源在某个时间之后更新了，那么客户端就应该下载最新的资源；如果没有更新，服务端会返回“304 Not Modified”的响应，那客户端就不用下载了，也会节省带宽。
常用头字段
通用字段：在请求头和响应头里都可以出现；
请求字段：仅能出现在请求头里，进一步说明请求信息或者额外的附加条件；
响应字段：仅能出现在响应头里，补充说明响应报文的信息；
实体字段：它实际上属于通用字段，但专门描述 body 的额外信息。
HTTP 的报文结构
1. HTTP 报文结构就像是“大头儿子”，由“起始行 + 头部 + 空行 + 实体”组成，简单地说就是“header+body”；
2. HTTP 报文可以没有 body，但必须要有 header，而且 header 后也必须要有空行，形象地说就是“大头”必须要带着“脖子”；
3. 请求头由“请求行 + 头部字段”构成，响应头由“状态行 + 头部字段”构成；
4. 请求行有三部分：请求方法，请求目标和版本号；
5. 状态行也有三部分：版本号，状态码和原因字符串；
6. 头部字段是 key-value 的形式，用“:”分隔，不区分大小写，顺序任意，除了规定的标准头，也可以任意添加自定义字段，实现功能扩展；
7. HTTP/1.1 里唯一要求必须提供的头字段是 Host，它必须出现在请求头里，标记虚拟主机名。
请求方法的安全与幂等。
1. 所谓的“安全”是指请求方法不会“破坏”服务器上的资源，即不会对服务器上的资源造成实质的修改。
2.所谓的“幂等”实际上是一个数学用语，被借用到了 HTTP 协议里，意思是多次执行相同的操作，结果也都是相同的，即多次“幂”后结果“相等”。
HTTP请求的发送
浏览器会将域名发送给 DNS 服务器，让它解析为 IP 地址。
HTTP 是基于 TCP 协议的，要先通过三次握手建立 TCP 连接
目前使用的 HTTP 协议大部分都是 1.1。在 1.1 的协议里面，默认是开启了 Keep-Alive 的，这样建立的 TCP 连接，就可以在多次请求中复用。
1.HTTP 协议是基于 TCP 协议的，所以它使用面向连接的方式发送请求，通过 stream 二进制流的方式传给对方。当然，到了 TCP 层，它会把二进制流变成一个个报文段发送给服务器。
2.在发送给每个报文段的时候，都需要对方有一个回应 ACK，来保证报文可靠地到达了对方。如果没有回应，那么 TCP 这一层会进行重新传输，直到可以到达。同一个包有可能被传了好多次，但是 HTTP 这一层不需要知道这一点，因为是 TCP 这一层在埋头苦干。
3.TCP 层发送每一个报文的时候，都需要加上自己的地址（即源地址）和它想要去的地方（即目标地址），将这两个信息放到 IP 头里面，交给 IP 层进行传输。
4.IP 层需要查看目标地址和自己是否是在同一个局域网。如果是，就发送 ARP 协议来请求这个目标地址对应的 MAC 地址，然后将源 MAC 和目标 MAC 放入 MAC 头，发送出去即可；如果不在同一个局域网，就需要发送到网关，还要需要发送 ARP 协议，来获取网关的 MAC 地址，然后将源 MAC 和网关 MAC 放入 MAC 头，发送出去。
5.网关收到包发现 MAC 符合，取出目标 IP 地址，根据路由协议找到下一跳的路由器，获取下一跳路由器的 MAC 地址，将包发给下一跳路由器。
6.这样路由器一跳一跳终于到达目标的局域网。这个时候，最后一跳的路由器能够发现，目标地址就在自己的某一个出口的局域网上。于是，在这个局域网上发送 ARP，获得这个目标地址的 MAC 地址，将包发出去。
7.目标的机器发现 MAC 地址符合，就将包收起来；发现 IP 地址符合，根据 IP 头中协议项，知道自己上一层是 TCP 协议，于是解析 TCP 的头，里面有序列号，需要看一看这个序列包是不是我要的，如果是就放入缓存中然后返回一个 ACK，如果不是就丢弃。
8.TCP 头里面还有端口号，HTTP 的服务器正在监听这个端口号。于是，目标机器自然知道是 HTTP 服务器这个进程想要这个包，于是将包发给 HTTP 服务器。HTTP 服务器的进程看到，原来这个请求是要访问一个网页，于是就把这个网页发给客户端。
HTTP返回的构建
1.状态行:服务器响应的状态
版本号：表示报文使用的 HTTP 协议版本；
状态码：一个三位数，用代码的形式表示处理的结果，比如 200 是成功，500 是服务器错误；
1××：提示信息，表示目前是协议处理的中间状态，还需要后续的操作；
2××：成功，报文已经收到并被正确处理；
3××：重定向，资源位置发生变动，需要客户端重新发送请求；
4××：客户端错误，请求报文有误，服务器无法处理；
5××：服务器错误，服务器在处理请求时内部发生了错误。
原因：作为数字状态码补充，是更详细的解释文字，帮助人理解原因。
2.首部字段: key value
1.Retry-After:告诉客户端应该在多长时间以后再重新尝试一下, 503错误是说:服务暂时不再和这个值配合使用
Content-Type: 正文格式(HTML,JSON)
3.当浏览器拿到了HTML的报文,发现返回200,一切正常,于是就从正文中将HTML拿出来,根据这个格式,展示网页
3. HTTP返回的过程
1. 构造好了返回的 HTTP 报文，接下来就是把这个报文发送出去。还是交给 Socket 去发送，还是交给 TCP 层，让 TCP 层将返回的 HTML，也分成一个个小的段，并且保证每个段都可靠到达。
2. 这些段加上 TCP 头后会交给 IP 层，然后把刚才的发送过程反向走一遍。虽然两次不一定走相同的路径，但是逻辑过程是一样的，一直到达客户端。
3. 客户端发现 MAC 地址符合、IP 地址符合，于是就会交给 TCP 层。根据序列号看是不是自己要的报文段，如果是，则会根据 TCP 头中的端口号，发给相应的进程。这个进程就是浏览器，浏览器作为客户端也在监听某个端口。
4. 当浏览器拿到了 HTTP 的报文。发现返回“200”，一切正常，于是就从正文中将 HTML 拿出来。HTML 是一个标准的网页格式。浏览器只要根据这个格式，展示出一个绚丽多彩的网页。
HTTPS协议
加密方式
对称加密：加密解密用的同一个钥匙
非对称加密：公钥加密，私钥解密
客户端给外卖网站发送的时候，用外卖网站的公钥加密。而外卖网站给客户端发送消息的时候，使用客户端的公钥。这样就算有黑客企图模拟客户端获取一些信息，或者半路截获回复信息，但是由于它没有私钥，这些信息它还是打不开
数字证书
证书里面有什么呢？当然应该有公钥，这是最重要的；还有证书的所有者;另外还有证书的发布机构和证书的有效期;权威机构我们称为 CA（ Certificate Authority）
将这个请求发给权威机构，权威机构会给这个证书卡一个章，我们称为签名算法
签名算法大概是这样工作的：一般是对信息做一个 Hash 计算，得到一个 Hash 值，这个过程是不可逆的，也就是说无法通过 Hash 值得出原来的信息内容。在把信息发送出去时，把这个 Hash 值加密后，作为一个签名和信息一起发出去
通过这种层层授信背书的方式，从而保证了非对称加密模式的正常运转。
HTTPS 的工作模式（此过程为RSA）
1. 在 TCP 建立连接之后，首先是TLS握手，用的握手协议
客户端会发送 Client Hello 消息到服务器，以明文传输 TLS 版本信息、加密套件候选列表、压缩算法候选列表等信息。还有一个随机数，在协商对称密钥的时候使用。
”然后，服务器返回 Server Hello 消息, 告诉客户端，服务器选择使用的协议版本、加密套件、压缩算法等，还有一个随机数，用于后续的密钥协商。
”然后，服务器为了证明自己，服务器会给你一个服务器端的证书，然后说：“Server Hello Done，我这里就这些信息了。
”你当然不相信这个证书，于是你从自己信任的 CA 仓库中，拿 CA 的证书里面的公钥去解密外卖网站的证书。如果能够成功，则说明服务器是可信的。这个过程中，你可能会不断往上追溯 CA、CA 的 CA、CA 的 CA 的 CA，反正直到一个授信的 CA，就可以了。
证书验证完毕之后，觉得这个服务器可信，于是客户端计算产生随机数字 Pre-master，发送 Client Key Exchange，用证书中的公钥加密，再发送给服务器，服务器可以通过私钥解密出来。
到目前为止，无论是客户端还是服务器，都有了三个随机数，分别是：自己的、对端的，以及刚生成的 Pre-Master 随机数。通过这三个随机数，可以在客户端和服务器产生相同的对称密钥。
2. 然后是变更密码规范协议（Change Cipher Spec Protocol），就是一个“通知”，告诉对方，后续的数据都将使用加密保护。因为在它之前，数据都是明文的。
有了对称密钥，客户端发送“Change Cipher Spec，告知以后都采用协商的通信密钥和加密算法进行加密通信。
”然后发送一个 Encrypted Handshake Message（加密握手消息），将已经商定好的参数等，采用协商密钥进行加密，发送给服务器用于数据与握手验证。（把之前所有发送的数据做个摘要，再加密一下，让服务器做个验证。）
同样，服务器也可以发送 Change Cipher Spec，告诉客户端，以后都采用协商的通信密钥和加密算法进行加密通信”，
并且也发送 Encrypted Handshake Message（加密握手消息）的消息试试。（把之前所有发送的数据做个摘要，再加密一下，让客户端做个验证。）
当双方握手结束之后，就可以通过对称密钥进行加密传输了。
这个过程除了加密解密之外，其他的过程和 HTTP 是一样的
重放与篡改
其实，这里还有一些没有解决的问题，例如重放和篡改的问题。没错，有了加密和解密，黑客截获了包也打不开了，但是它可以发送 N 次。这个往往通过 Timestamp 和 Nonce 随机数联合起来，然后做一个不可逆的签名来保证。Nonce 随机数保证唯一，或者 Timestamp 和 Nonce 合起来保证唯一，同样的，请求只接受一次，于是服务器多次收到相同的 Timestamp 和 Nonce，则视为无效即可。如果有人想篡改 Timestamp 和 Nonce，还有签名保证不可篡改性，如果改了用签名算法解出来，就对不上了，可以丢弃了。
加密算法
FTP，也即文件传输协议
FTP 采用两个 TCP 连接来传输一个文件。
控制连接：服务器以被动的方式，打开众所周知用于 FTP 的端口 21，客户端则主动发起连接。该连接将命令从客户端传给服务器，并传回服务器的应答。常用的命令有：list——获取文件目录；reter——取一个文件；store——存一个文件。
数据连接：每当一个文件在客户端与服务器之间传输时，就创建一个数据连接。
FTP 的两种工作模式
每传输一个文件，都要建立一个全新的数据连接。FTP 有两种工作模式，分别是主动模式（PORT）和被动模式（PASV）
主动模式下，客户端随机打开一个大于 1024 的端口 N，向服务器的命令端口 21 发起连接，同时开放 N+1 端口监听，并向服务器发出 “port N+1” 命令，由服务器从自己的数据端口 20，主动连接到客户端指定的数据端口 N+1。
被动模式下，当开启一个 FTP 连接时，客户端打开两个任意的本地端口 N（大于 1024）和 N+1。第一个端口连接服务器的 21 端口，提交 PASV 命令。然后，服务器会开启一个任意的端口 P（大于 1024），返回“227 entering passive mode”消息，里面有 FTP 服务器开放的用来进行数据传输的端口。客户端收到消息取得端口号之后，会通过 N+1 号端口连接服务器的端口 P，然后在两个端口之间进行数据传输。
P2P协议
P2P 就是 peer-to-peer。资源开始并不集中地存储在某些设备上，而是分散地存储在多台设备上
DNS协议
DNS 服务器:一定要设置成高可用、高并发和分布式的。
树状的层次结构
1. 先查询浏览器的本地缓存（通常在内存中）
2. 本地没缓存，查找操作系统的hosts文件，该文件在Linux中在/etc/hosts
3. 上述步骤没有找到，DNS会查询本地服务提供商（ISP）
4. ISP没找到，请求指向Root根服务器，返回顶级域名服务器地址
5. 浏览器发送请求给顶级域名服务器，返回权威域名服务器地址
6. 浏览器发送Lookup请求给权威域名服务器，找到具体DNS记录，返回给浏览器
DNS 解析流程
负载均衡
站在客户端角度，这是一次 DNS 递归查询过程。因为本地 DNS 全权为它效劳，它只要坐等结果即可。在这个过程中，DNS 除了可以通过名称映射为 IP 地址，它还可以做另外一件事，就是负载均衡。
DNS内部负载均衡
1. 一个应用要访问数据库，在这个应用里面应该配置这个数据库的 IP 地址，还是应该配置这个数据库的域名呢？显然应该配置域名，因为一旦这个数据库，因为某种原因，换到了另外一台机器上，而如果有多个应用都配置了这台数据库的话，一换 IP 地址，就需要将这些应用全部修改一遍。但是如果配置了域名，则只要在 DNS 服务器里，将域名映射为新的 IP 地址，这个工作就完成了，大大简化了运维。
2.某个应用要访问另外一个应用，如果配置另外一个应用的 IP 地址，那么这个访问就是一对一的。但是当被访问的应用撑不住的时候，我们其实可以部署多个。但是，访问它的应用，如何在多个之间进行负载均衡？只要配置成为域名就可以了。在域名解析的时候，我们只要配置策略，这次返回第一个 IP，下次返回第二个 IP，就可以实现负载均衡了。
DNS全局负载均衡
1.为了保证我们的应用高可用，往往会部署在多个机房，每个地方都会有自己的 IP 地址。当用户访问某个域名的时候，这个 IP 地址可以轮询访问多个数据中心。如果一个数据中心因为某种原因挂了，只要在 DNS 服务器里面，将这个数据中心对应的 IP 地址删除，就可以实现一定的高可用。
2.另外，我们肯定希望北京的用户访问北京的数据中心，上海的用户访问上海的数据中心，这样，客户体验就会非常好，访问速度就会超快。这就是全局负载均衡的概念。
透视HTTP协议
1.什么是HTTP协议?
HTTP 是一个用在计算机世界里的协议，它确立了一种计算机之间交流通信的规范，以及相关的各种控制和错误处理方式。
HTTP 专门用来在两点之间传输数据，不能用于广播、寻址或路由。
HTTP 传输的是文字、图片、音频、视频等超文本数据。
HTTP 是构建互联网的重要基础技术，它没有实体，依赖许多其他的技术来实现，但同时许多技术也都依赖于它。
2.你能用自己的话解释一下“二层转发”“三层路由”吗？你认为上一讲中的 DNS 协议位于哪一层呢？你认为 CDN 工作在那一层呢？
1 二层转发：设备工作在链路层，帧在经过交换机设备时，检查帧的头部信息，拿到目标mac地址，进行本地转发和广播
2 三层路由：设备工作在ip层，报文经过有路由功能的设备时，设备分析报文中的头部信息，拿到ip地址，根据网段范围，进行本地转发或选择下一个网关
3 dns，网络请求的第一步是域名解析，所以工作在应用层
4 cdn，应用层
3.在浏览器地址栏里随便输入一个不存在的域名，比如就叫“www. 不存在.com”，试着解释一下它的 DNS 解析过程。如果因为某些原因，DNS 失效或者出错了，会出现什么后果？
1.浏览器缓存 -> OS 缓存 -> hosts 文件 -> 本地域名服务器 -> 根域名服务器 -> 顶级域名服务器 -> 权威域名服务器
2.客户端向本地域名服务器获取，是递归查询,本地域名服务器向根域名服务器获取，可以是递归也可是迭代,递归就是你交给别人，让别人查到，在返回给你,迭代就是你找别人要，他叫你去别的地方找
4.HTTP 协议请求 - 应答的全过程总结
HTTP 协议基于底层的 TCP/IP 协议，所以必须要用 IP 地址建立连接；
如果不知道 IP 地址，就要用 DNS 协议去解析得到 IP 地址，否则就会连接失败；
建立 TCP 连接后会顺序收发数据，请求方和应答方都必须依据 HTTP 规范构建和解析报文；
为了减少响应时间，整个过程中的每一个环节都会有缓存，能够实现“短路”操作；
虽然现实中的 HTTP 传输过程非常复杂，但理论上仍然可以简化成实验里的“两点”模型。
5.在浏览器里点击页面链接后发生了哪些事情
浏览器判断是不是ip地址，不是就进行域名解析，依次通过浏览器缓存，系统缓存，host文件，还是没找到的请求DNS服务器获取IP解析(解析失败的浏览器尝试换别的DNS服务器，最终失败的进入错误页面)，有可能获取到CDN服务器IP地址，访问CDN时先看是否缓存了，缓存了响应用户，无法缓存，缓存失效或者无缓存，回源到服务器。经过防火墙外网网管路由到nginx接入层。ng缓存中存在的直接放回，不存在的负载到web服务器。web服务器接受到请后处理，路径不存在404。存在的返回结果(服务器中也会有redis,ehcache(堆内外缓存)，disk等缓存策略)。原路返回，CDN加入缓存响应用户。
5. 如果拼 HTTP 报文的时候，在头字段后多加了一个 CRLF，导致出现了一个空行，会发生什么？讲头字段时说“:”后的空格可以有多个，那为什么绝大多数情况下都只使用一个空格呢？
1.在header 下面第一个空行以后都会被当作body 体
2.头部多一个空格就会多一个传输的字节，去掉无用的信息，保证传输的头部字节数尽量小
6.HTTP有哪些特点？
1. HTTP 是灵活可扩展的，可以任意添加头字段实现任意功能；
2. HTTP 是可靠传输协议，基于 TCP/IP 协议“尽量”保证数据的送达；
3. HTTP 是应用层协议，比 FTP、SSH 等更通用功能更多，能够传输任意数据；
4. HTTP 使用了请求 - 应答模式，客户端主动发起请求，服务器被动回复请求；+
5. HTTP 本质上是无状态的，每个请求都是互相独立、毫无关联的，协议不要求客户端或服务器记录请求相关的信息。
HTTPS
什么是安全？
如果通信过程具有机密性、完整性，身份认证和不可否认，就可以认为他是安全的
1. 机密性（Secrecy/Confidentiality）是指对数据的“保密”，只能由可信的人访问，对其他人是不可见的“秘密”，简单来说就是不能让不相关的人看到不该看的东西。
对称加密和非对称加密，以及两者结合起来的混合加密，实现了机密性。
2. 完整性（Integrity，也叫一致性）是指数据在传输过程中没有被篡改，不多也不少，“完完整整”地保持着原状。
实现完整性的手段主要是摘要算法（Digest Algorithm）
3. 身份认证（Authentication）是指确认对方的真实身份，也就是“证明你真的是你”，保证消息只能发送给可信的人。
4. 不可否认（Non-repudiation/Undeniable），也叫不可抵赖，意思是不能否认已经发生过的行为，不能“说话不算数”“耍赖皮”。使用前三个特性，可以解决安全通信的大部分问题，但如果缺了不可否认，那通信的事务真实性就得不到保证，有可能出现“老赖”。
什么是 HTTPS？
HTTPS=HTTP+SSL/TLS
HTTPS 其实是一个“非常简单”的协议。
里面规定了新的协议名“https”，默认端口号 443，至于其他的什么请求 - 应答模式、报文结构、请求方法、URI、头字段、连接管理等等都完全沿用 HTTP，没有任何新的东西。
也就是说，除了协议名“http”和端口号 80 这两点不同，HTTPS 协议在语法、语义上和 HTTP 完全一样，优缺点也“照单全收”（当然要除去“明文”和“不安全”）。
SSL/TLS
SSL 即安全套接层（Secure Sockets Layer），在 OSI 模型中处于第 5 层（会话层）
TLS 由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成，综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。
浏览器和服务器在使用 TLS 建立连接时需要选择一组恰当的加密算法来实现安全通信，这些算法的组合被称为“密码套件”（cipher suite，也叫加密套件）。
TLS 的密码套件命名非常规范，格式很固定。基本的形式是“密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法”
ECDHE-RSA-AES256-GCM-SHA384
“握手时使用 ECDHE 算法进行密钥交换，用 RSA 签名和身份认证，握手后的通信使用 AES 对称算法，密钥长度 256 位，分组模式是 GCM，摘要算法 SHA384 用于消息认证和产生随机数。”
TLS 协议的组成
TLS 包含几个子协议。比较常用的有记录协议、警报协议、握手协议、变更密码规范协议等。
记录协议（Record Protocol）规定了 TLS 收发数据的基本单位：记录（record）。它有点像是 TCP 里的 segment，所有的其他子协议都需要通过记录协议发出。但多个记录数据可以在一个 TCP 包里一次性发出，也并不需要像 TCP 那样返回 ACK。
警报协议（Alert Protocol）的职责是向对方发出警报信息，有点像是 HTTP 协议里的状态码。比如，protocol_version 就是不支持旧版本，bad_certificate 就是证书有问题，收到警报后另一方可以选择继续，也可以立即终止连接。
握手协议（Handshake Protocol）是 TLS 里最复杂的子协议，要比 TCP 的 SYN/ACK 复杂的多，浏览器和服务器会在握手过程中协商 TLS 版本号、随机数、密码套件等信息，然后交换证书和密钥参数，最终双方协商得到会话密钥，用于后续的混合加密系统。
变更密码规范协议（Change Cipher Spec Protocol），它非常简单，就是一个“通知”，告诉对方，后续的数据都将使用加密保护。那么反过来，在它之前，数据都是明文的。
多个记录组合成一个 TCP 包发送
HTTPS中RSA握手过程
1. 在 TCP 建立连接之后，首先是TLS握手，用的握手协议
客户端会发送 Client Hello 消息到服务器，以明文传输 TLS 版本信息、加密套件候选列表、压缩算法候选列表等信息。还有一个随机数，在协商对称密钥的时候使用。
”然后，服务器返回 Server Hello 消息, 告诉客户端，服务器选择使用的协议版本、加密套件、压缩算法等，还有一个随机数，用于后续的密钥协商。
”然后，服务器为了证明自己，服务器会给你一个服务器端的证书，然后说：“Server Hello Done，我这里就这些信息了。
”你当然不相信这个证书，于是你从自己信任的 CA 仓库中，拿 CA 的证书里面的公钥去解密外卖网站的证书。如果能够成功，则说明服务器是可信的。这个过程中，你可能会不断往上追溯 CA、CA 的 CA、CA 的 CA 的 CA，反正直到一个授信的 CA，就可以了。
证书验证完毕之后，觉得这个服务器可信，于是客户端计算产生随机数字 Pre-master，发送 Client Key Exchange，用证书中的公钥加密，再发送给服务器，服务器可以通过私钥解密出来。
到目前为止，无论是客户端还是服务器，都有了三个随机数，分别是：自己的、对端的，以及刚生成的 Pre-Master 随机数。通过这三个随机数，可以在客户端和服务器产生相同的对称密钥。
2. 然后是变更密码规范协议（Change Cipher Spec Protocol），就是一个“通知”，告诉对方，后续的数据都将使用加密保护。因为在它之前，数据都是明文的。
有了对称密钥，客户端发送“Change Cipher Spec，告知以后都采用协商的通信密钥和加密算法进行加密通信。
”然后发送一个 Encrypted Handshake Message（加密握手消息），将已经商定好的参数等，采用协商密钥进行加密，发送给服务器用于数据与握手验证。（把之前所有发送的数据做个摘要，再加密一下，让服务器做个验证。）
同样，服务器也可以发送 Change Cipher Spec，告诉客户端，以后都采用协商的通信密钥和加密算法进行加密通信”，
并且也发送 Encrypted Handshake Message（加密握手消息）的消息试试。（把之前所有发送的数据做个摘要，再加密一下，让客户端做个验证。）
当双方握手结束之后，就可以通过对称密钥进行加密传输了。
这个过程除了加密解密之外，其他的过程和 HTTP 是一样的
对称加密与非对称加密
对称加密
“对称加密”很好理解，就是指加密和解密时使用的密钥都是同一个，是“对称”的。只要保证了密钥的安全，那整个通信过程就可以说具有了机密性。
TLS 里有非常多的对称加密算法可供选择，比如 RC4、DES、3DES、AES、ChaCha20 等，但前三种算法都被认为是不安全的，通常都禁止使用，目前常用的只有 AES 和 ChaCha20。
AES 的意思是“高级加密标准”（Advanced Encryption Standard），密钥长度可以是 128、192 或 256。它是 DES 算法的替代者，安全强度很高，性能也很好，而且有的硬件还会做特殊优化，所以非常流行，是应用最广泛的对称加密算法。
ChaCha20 是 Google 设计的另一种加密算法，密钥长度固定为 256 位，纯软件运行性能要超过 AES，曾经在移动客户端上比较流行，但 ARMv8 之后也加入了 AES 硬件优化，所以现在不再具有明显的优势，但仍然算得上是一个不错的算法。
加密分组模式
分组模式：DES和AES都属于分组密码，它们只能加密固定长度的明文。如果需要加密任意长度的明文，就需要对分组密码进行迭代，而分组密码的迭代方法就称为分组密码的“模式”。
主要模式：
ECB模式：Electronic Code Book mode（电子密码本模式）
CBC模式：Cipher Block Chaining mode（密码分组链接模式）（推荐使用）
CFB模式：Cipher FeedBack mode（密文反馈模式）
OFB模式：Output FeedBack mode（输出反馈模式）
CTR模式：CounTeR mode（计数器模式）（推荐使用）拿ECB来举例子，假设使用aes128，密钥长度是16字节，那么就把明文按16字节分组，然后每个分组用密钥加密。
非对称加密
非对称加密算法的设计要比对称算法难得多，在 TLS 里只有很少的几种，比如 DH、DSA、RSA、ECC 等。
RSA 可能是其中最著名的一个，几乎可以说是非对称加密的代名词，它的安全性基于“整数分解”的数学难题，使用两个超大素数的乘积作为生成密钥的材料，想要从公钥推算出私钥是非常困难的。10 年前 RSA 密钥的推荐长度是 1024，但随着计算机运算能力的提高，现在 1024 已经不安全，普遍认为至少要 2048 位。
ECC（Elliptic Curve Cryptography）是非对称加密里的“后起之秀”，它基于“椭圆曲线离散对数”的数学难题，使用特定的曲线方程和基点生成公钥和私钥，子算法 ECDHE 用于密钥交换，ECDSA 用于数字签名。
比起 RSA，ECC 在安全强度和性能上都有明显的优势。160 位的 ECC 相当于 1024 位的 RSA，而 224 位的 ECC 则相当于 2048 位的 RSA。因为密钥短，所以相应的计算量、消耗的内存和带宽也就少，加密解密的性能就上去了，对于现在的移动互联网非常有吸引力。
TLS 里使用的混合加密方式
在通信刚开始的时候使用非对称算法，比如 RSA、ECDHE，首先解决密钥交换的问题。
然后用随机数产生对称算法使用的“会话密钥”（session key），再用公钥加密。因为会话密钥很短，通常只有 16 字节或 32 字节，所以慢一点也无所谓。
对方拿到密文后用私钥解密，取出会话密钥。这样，双方就实现了对称密钥的安全交换，后续就不再使用非对称加密，全都使用对称加密。
简单来说，SSL 就是通信双方通过非对称加密协商出一个用于对称加密的密钥。
非对称加密为什么慢，非对称加密除了慢外还有什么缺点
非对称加密基于大数运算，比如大素数或者椭圆曲线，是复杂的数学难题，所以消耗计算量，运算速度慢。
除了慢，可能还有一个缺点就是需要更多的位数，相同强度的对称密钥要比非对称密钥短。
对称密钥一般都128位、256位，而rsa一般要2048位，不过椭圆曲线的会短一点。
数字签名与证书
摘要算法
实现完整性的手段主要是摘要算法（Digest Algorithm），也就是常说的散列函数、哈希函数（Hash Function）。
能够把任意长度的数据“压缩”成固定长度、而且独一无二的“摘要”字符串
也可以把摘要算法理解成特殊的“单向”加密算法，它只有算法，没有密钥，加密后的数据无法解密，不能从摘要逆推出原文。
因为摘要算法对输入具有“单向性”和“雪崩效应”，输入的微小不同会导致输出的剧烈变化，所以也被 TLS 用来生成伪随机数（PRF，pseudo random function）。
完整性
摘要算法保证了“数字摘要”和原文是完全等价的。所以，我们只要在原文后附上它的摘要，就能够保证数据的完整性。
真正的完整性必须要建立在机密性之上，在混合加密系统里用会话密钥加密消息和摘要，这样黑客无法得知明文，也就没有办法动手脚了。
数字签名
使用私钥再加上摘要算法，就能够实现“数字签名”，同时实现“身份认证”和“不可否认
数字签名的原理：私钥加密、公钥解密
因为非对称加密效率太低，所以私钥只加密原文的摘要，这样运算量就小的多，而且得到的数字签名也很小，方便保管和传输。
签名和公钥一样完全公开，任何人都可以获取。但这个签名只有用私钥对应的公钥才能解开，拿到摘要后，再比对原文验证完整性，就可以像签署文件一样证明消息确实是你发的。
只要你和网站互相交换公钥，就可以用“签名”和“验签”来确认消息的真实性，因为私钥保密，黑客不能伪造签名，就能够保证通信双方的身份。
数字证书和 CA
这个“第三方”就是我们常说的 CA（Certificate Authority，证书认证机构）。它就像网络世界里的公安局、教育部、公证中心，具有极高的可信度，由它来给各个公钥签名，用自身的信誉来保证公钥无法伪造，是可信的。
CA 对公钥的签名认证也是有格式的，不是简单地把公钥绑定在持有者身份上就完事了，还要包含序列号、用途、颁发者、有效时间等等，把这些打成一个包再签名，完整地证明公钥关联的各种信息，形成“数字证书”（Certificate）。
CA 怎么证明自己呢？
这还是信任链的问题。小一点的 CA 可以让大 CA 签名认证，但链条的最后，也就是 Root CA，就只能自己证明自己了，这个就叫“自签名证书”（Self-Signed Certificate）或者“根证书”（Root Certificate）。你必须相信，否则整个证书信任链就走不下去了。
有了这个证书体系，操作系统和浏览器都内置了各大 CA 的根证书，上网的时候只要服务器发过来它的证书，就可以验证证书里的签名，顺着证书链（Certificate Chain）一层层地验证，直到找到根证书，就能够确定证书是可信的，从而里面的公钥也是可信的。
网络高并发负载均衡
常用命令:
#查看路由表
route -n
#查看网络状态
netstat -natp
#查看文件描述符
ll /proc/$$/fd
#查看已打开的文件
lsof -p $$
#创建一个socket通信,由内核内部完成
exec 5<> /dev/tcp/node02/6379
#发送数据,用户实现应用层协议
echo "keys *" >&5
#请求百度的主页
curl www.baidu.com
安装抓包工具
yum install tcpdump -y
#网络抓包
tcpdump -nn -i eth0 port 80
第一步建立连接第二步才是传送数据（http协议：规范标准）
最终给你演示的是一个应用层协议
创建socket通信,实现与远程Redis通信
网络层交互
LVS负载均衡
模型1 NAT模式
模型2 DR模式(企业多用这种)
模型3 TUN隧道技术
路由器
DR模式访问原理
LVS：搭建步骤
node01:
ifconfig eth0:8 192.168.150.100/24
node02~node03:
1)修改内核：
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
2）设置隐藏的vip：
ifconfig lo:3 192.168.150.100 netmask 255.255.255.255
RS中的服务：
node02~node03:
yum install httpd -y
service httpd start
vi /var/www/html/index.html
from 192.168.150.1xLVS服务配置
node01:
yum install ipvsadm
ipvsadm -A -t 192.168.150.100:80 -s rr
ipvsadm -a -t 192.168.150.100:80 -r 192.168.150.12 -g -w 1
ipvsadm -a -t 192.168.150.100:80 -r 192.168.150.13 -g -w 1
ipvsadm -ln验证：
浏览器访问 192.168.150.100 看到负载 疯狂F5
node01：
netstat -natp 结论看不到socket连接
node02~node03:
netstat -natp 结论看到很多的socket连接
node01:
ipvsadm -lnc 查看偷窥记录本
TCP 00:57 FIN_WAIT 192.168.150.1:51587 192.168.150.100:80 192.168.150.12:80
FIN_WAIT： 连接过，偷窥了所有的包
SYN_RECV： 基本上lvs都记录了，证明lvs没事，一定是后边网络层出问题
keepalived实验：
主机： node01~node04
node01:
ipvsadm -C
ifconfig eth0:8 down----------------------------
node01,node04:
yum install keepalived ipvsadm -y
配置：
cd /etc/keepalived/
cp keepalived.conf keepalived.conf.bak
vi keepalived.conf
node01:
vrrp：虚拟路由冗余协议！
vrrp_instance VI_1 {
state MASTER // node04 BACKUP
interface eth0
virtual_router_id 51
priority 100 // node04 50
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.150.100/24 dev eth0 label eth0:3
}
}
virtual_server 192.168.150.100 80 {
delay_loop 6
lb_algo rr
lb_kind DR
nat_mask 255.255.255.0
persistence_timeout 0
protocol TCPreal_server 192.168.150.12 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.150.13 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
scp ./keepalived.conf root@node04:`pwd`
扫一扫
23万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
