计算机网络

两个线程之间传递消息用对列

---

1、三次握手、四次挥手

三次握手
1.发送SYN报文
客户端发送报文，SYN为1，序列号为seq=m，状态SYN_SEND
2.服务端SYN+ACK
服务端收到回应ACK+SYN为１，序列号n，确认好m+1，SYN_REVD
3.客户端回应ACK
ACK为1，号为n+1，同时可以发送数据，建立状态

2、为什么需要三次握手?

总结:
1．三次握手才可以阻止重复历史连接的初始化(主因)
2.三次握手才可以同步双方的初始序列号
3．三次握手才可以避免资源浪费
解释:
1、阻止重复历史连接的初始化(主因)

• 当旧的SYIN报文先到达服务端，服务端回一个ACK+SYN报文
• 客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列号过期或超时)，那么客户端就会发送RST报文给服务端,表示中止这一次连接。

两次握手在收到服务端的响应后开始发生数据，不能判断当前连接是否是历史连接
三次握手可以在客户端准备发送第三次报文时，客户端因有足够的上下文来判断当前连接是否是历史连接。
2、同步双方的初始序列号
TCP协议的通信双方，都必须维护一个「序列号」，序列号是可靠传输的一个关键因素。

这样一来一回，才能确保双方的初始序列号能被可靠的同步。
两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收。
3、避免资源浪费。
1．两次握手会造成消息滞留情况下，服务器重复接受无用的连接请求SYN报文
而造成重复分配资源。
2.只有两次握手时，如果客户端的SYN请求连接在网络中阻塞，客户端没有收到服务端的ACK报文，会重新发送SYN。
3.由于没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的ACK 确认信号，所以每收到一个SYN 就只能先主动建立一个连接。

四次挥手

1.客户端发送FIN=1报文
2.服务端回应ACK=1
3.服务端处理完成发送FIN=1
4.客户端回应ACK
5.服务端收到关闭
6.客户端等到2MSL关闭

3、为什么挥手需要四次?

关闭连接时，客户端发送FIN报文，表示其不再发送数据，但还可以接收数据。客户端收到FIN报文，先回一个ACK应答报文，服务端可能还要数据需要处理和发等到其不再发送数据时，才发送FIN报文给客户端表示同意关闭连接。
从上面过程可知:
1．服务端通常需要等待完成数据的发送和处理，所以服务端的ACK和FIN一般都会分开发送，从而比三次握手导致多了一次。
2．第一次ACK应答报文可以省略，因为下一个报文段携带了ACK信息，ACK是否出现取决于延迟确认特性。
3.延迟确认∶即接收方收到包后，如果暂时没有内容回复给发送方，则延迟一段时间再确认，假如在这个时间范围内刚好有数据需要传输，则和确认包一起回复。这种也被称为数据捎带。延迟确认只是减轻网络负担，未必可以提升网络性能，有些情况下反而会影响性能。

4、为什么TIME_WAIT 等待的时间是2MSL?

1.MSL是 Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这
个时间报文将被丢弃。
2．等待MSL两倍:网络中可能存在发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待2倍的时间。
3.2MSL 的时间是从客户端接收到FIN后发送 ACK开始计时的。如果在TIME-WAIT时间内，因为客户端的ACK没有传输到服务端，客户端又接收到了服务端重发的FIN报文，那么2MSL时间将重新计时。

5、HTTP/HTTPS

HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。

HTTP 最突出的优点是「简单、灵活和易于扩展、应用广泛和跨平台」。

1. 简单

HTTP 基本的报文格式就是 header + body，头部信息也是 key-value 简单文本的形式，易于理解，降低了学习和使用的门槛。

2. 灵活和易于扩展

HTTP 协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。
同时 HTTP 由于是工作在应用层（ OSI 第七层），则它下层可以随意变化，比如：
HTTPS 就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层；
HTTP/1.1 和 HTTP/2.0 传输协议使用的是 TCP 协议，而到了 HTTP/3.0 传输协议改用了 UDP 协议。
3. 应用广泛和跨平台

互联网发展至今，HTTP 的应用范围非常的广泛，从台式机的浏览器到手机上的各种 APP，从看新闻、刷贴吧到购物、理财、吃鸡，HTTP 的应用遍地开花，同时天然具有跨平台的优越性。

HTTP/1.1 的缺点有哪些？
HTTP 协议里有优缺点一体的双刃剑，分别是「无状态、明文传输」，同时还有一大缺点「不安全」。

1. 无状态双刃剑

无状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务。

无状态的坏处，既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。

例如登录->添加购物车->下单->结算->支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要问一遍身份信息。

这样每操作一次，都要验证信息，这样的购物体验还能愉快吗？别问，问就是酸爽！

对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术。

Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。

相当于，在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了了，

2. 明文传输双刃剑
3. 不安全

HTTP 比较严重的缺点就是不安全：

通信使用明文（不加密），内容可能会被窃听。比如，账号信息容易泄漏，那你号没了。
不验证通信方的身份，因此有可能遭遇伪装。比如，访问假的淘宝、拼多多，那你钱没了。
无法证明报文的完整性，所以有可能已遭篡改。比如，网页上植入垃圾广告，视觉污染，眼没了。
HTTP 的安全问题，可以用 HTTPS 的方式解决，也就是通过引入 SSL/TLS 层，使得在安全上达到了极致。

性能
长连接、管道网络传输

6、HTTP 与 HTTPS 有哪些区别？

HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。

HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。

两者的默认端口不一样，HTTP 默认端口号是 80，HTTPS 默认端口号是 443。

HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。
采用「混合加密」的方式的原因：

对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。

HTTPS 是如何建立连接的？其间交互了什么？
SSL/TLS 协议基本流程：

客户端向服务器索要并验证服务器的公钥。
双方协商生产「会话秘钥」。
双方采用「会话秘钥」进行加密通信。
前两步也就是 SSL/TLS 的建立过程，也就是 TLS 握手阶段。

TLS 的「握手阶段」涉及四次通信，使用不同的密钥交换算法，TLS 握手流程也会不一样的，现在常用的密钥交换算法有两种：RSA 算法 (opens new window)和 ECDHE 算法 (opens new window)。

HTTPS 协议本身到目前为止还是没有任何漏洞的，即使你成功进行中间人攻击，本质上是利用了客户端的漏洞（用户点击继续访问或者被恶意导入伪造的根证书），并不是 HTTPS 不够安全。
纯裸 TCP 是能收发数据，但它是个无边界的数据流，上层需要定义消息格式用于定义消息边界。于是就有了各种协议，HTTP 和各类 RPC 协议就是在 TCP 之上定义的应用层协议。
RPC 本质上不算是协议，而是一种调用方式，而像 gRPC 和 Thrift 这样的具体实现，才是协议，它们是实现了 RPC 调用的协议。目的是希望程序员能像调用本地方法那样去调用远端的服务方法。同时 RPC 有很多种实现方式，不一定非得基于 TCP 协议。
从发展历史来说，HTTP 主要用于 B/S 架构，而 RPC 更多用于 C/S 架构。但现在其实已经没分那么清了，B/S 和 C/S 在慢慢融合。很多软件同时支持多端，所以对外一般用 HTTP 协议，而内部集群的微服务之间则采用 RPC 协议进行通讯。
RPC 其实比 HTTP 出现的要早，且比目前主流的 HTTP/1.1 性能要更好，所以大部分公司内部都还在使用 RPC。
HTTP/2.0 在 HTTP/1.1 的基础上做了优化，性能可能比很多 RPC 协议都要好，但由于是这几年才出来的，所以也不太可能取代掉 RPC。

7、DNS

(1）概念
1．DNS协议用来将域名转换为IP地址，也可将IP地址转换为相应的域名地址
2．DNS:面向用户IP:面向主机
3．域名服务主要是基于UDP实现的,服务器端口号为53
(2)解析过程
浏览器查询URL对应IP:浏览器缓存→操作系统缓存→路由器缓存;
三种类型的DNS服务器:根DNS服务器、顶级域DNS服务器、权威DNS服务器;
查询浏览器DNS缓存→查询系统hosts文件→请求本地域名服务器→根DNS→顶级DNS→权威DNS→返回主机

3、安全+幂等:
安全:HTTP协议中，安全是指请求方法不会破坏服务器上的资源
幂等:多次执行相同的操作,结果都相同
GET为安全幂等的，因为它为只读操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的

8、SYN攻击

1、原理
攻击者伪造不同IP地址的SYN报文请求连接，服务端收到连接请求后分配资源，回复ACK+SYN包，但是由于IP地址是伪造的，无法收到回应，久而久之造成服务端半连接队列被占满，无法正常工作

2、避免方式
(1)修改半连接队列大小
使服务端能够容纳更多半连接。此外还可以修改服务端超时重传次数，使服务端尽早丢弃无用连接
(2)正常服务端行为是收到客户端SYN报文后将其加入到内核半连接队列，接着发送ACK+SYN报文给客户端，当收到客户端ACK报文后把连接从半连接队列移动到accept队列。当半连接队列满时，启动syn cookie,后续连接不进入半连接队列，而是计算一个cookie值，作为请求报文序列号发送给客户端，如果服务端收到客户端确认报文，会检查ack包合法性，如果合法直接加入到accept队列

9、TCP拥塞控制

1、慢开始和拥塞避免
慢开始:TCP连接刚刚建立，一点一点的提速，试探一下网络的承受能力，以免扰乱了网络通信的秩序，慢慢的翻倍的提速
一开始是1，每过一个RTT往返时间之后，乘2，有一个慢启动的阈值，如果超过了这个阈值就会进入一个拥塞避免的阶段，然后从乘2变成加1的递增。
如果遇到网络拥塞的时候，拥塞窗口会直接变成1，然后拥塞窗口的阈值会降成当前阈值的一半，然后重新开始慢启动。
但是直接降为1，对传输会有很大的影响，就有后续的优化∶快速重传和快速恢复。
2、快速重传和快速恢复
当收到3个重复的ACK的时候执行快重传，将当前的窗口的值降为原来的一半
阈值也降为原来的一半，然后每次加1递增，把需要重传的都传完之后，就进入拥塞避免的阶段，每个RTT加1，然后进入正常流程

ARP地址解析协议通过IP获取MAC
DHCP

10、ICMP互联网控制报文协议

ICMP ( lInternet Control Message Protocol，也就是互联网控制报文协议)。
网络包在复杂的网络传输环境里，常常会遇到各种问题。当遇到问题的时候，总不能死个不明不白，没头没脑的作风不是计算机网络的风格。所以需要传出消息，报告遇到了什么问题，这样才可以调整传输策略，以此来控制整个局面。
(1)ICMP功能都有啥
ICMP的主要功能包括:确认IP包是否成功送达目标地址、报告发送过程中IP包被废弃的原因和改善网络设置等。在IP通信中如果某个IP包因为某种原因未能达到目标地址，那么这个具体的原因将由ICMP负责通知。
(2)ICMP的类型
ICMP大致可以分为两大类:
一类是用于诊断的查询消息，也就是「查询报文类型」一类是通知出错原因的错误消息，也就是「差错报文类型」
路由器和交换机是有区别的
因为路由器是基于IP设计的，俗称三层网络设备，路由器的各个端口都具有MAC地址和IP地址;
而交换机是基于以太网设计的，俗称二层网络设备，交换机的端口不具有MAC地址。