计算机网络

网络模型

• 应用层：为应用程序提供交互服务(http,ftp)
• 表示层：数据格式转换：加密解密、压缩解压
• 会话层：两点间建立、终止通信（DNS）
• 传输层：负责向两点通信提供数据传输服务（TCP/UDP）
• 网络层：选择合适的路由和交换结点，确保数据及时传送（IP）
• 数据链路层：将IP数据包组装成帧并传送
• 物理层：比特流的透明传输

七层和四层的区别

OSI七层模型是理论上的网络通信模型，先有模型后有协议

TCP/IP 四层模型是由实际发展总结出来的，参考七层，对协议再提出模型

TCP/IP协议

指能够在多个不同网络间实现信息传输的协议簇

是一个由FTP、SMTP、TCP、UDP、IP等协议构成的协议簇

HTTP

超文本传输协议

HTTP 是一个专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范

HTTP报文

由请求行、请求头、空行、请求体组成

请求行

请求方式：get / post

URL

HTTP版本：1.0 / 1.1 / 2.0

get / post

get是从服务器获取资源，数据拼接在请求头url中，不安全，限制长度

post 向 URI 指定的资源提交数据，数据就放在报文的 body 里，安全，不限长度

URL

URI和URL区别

URI：标识符，可以唯一标识一个资源
URL：定位符，通过这个路径可以找到资源

1. URL是URI的子集，一个URI可以对应多个URL
2. URI+协议+IP+端口+数据 = URL

HTTP版本

1.0

• 未加密不安全
• TCP短连接：每次请求都要建立TCP连接，服务器处理完后就断开连接；开销大
• 不支持断点续传：数据必须一次发完
• 队头阻塞：因为规定 一个请求应答之后下一个请求才能发送，如果前面的请求很久不被应答，后面的请求就会受到阻塞；

1.1

• 身份验证：利用摘要算法（MD5）对用户名、密码等内容做不可逆编码，防止信息被篡改
• 长链接：一次连接多次数据传输，完后切断
• 断点续传：从断开传输的点继续传输
• 支持管道传输：不必等第一个请求回来就可以发第二个请求出去，看样子是并行的，但是客户端接收数据的顺序需要和发送请求的顺序相同，还是会出现队头阻塞，所以现如今浏览器厂商都不这么用；浏览器允许客户端打开多个TCP连接，然后在这些连接中同时发出请求和接收数据，这才是真正的并行。

2.0

• 头部压缩：消除重复部分；比如说头部携带的token就不用重复的发
• 二进制分帧：在HTTP层和TCP层加入增加了一个二进制分帧层，将信息分为更小的消息和帧；采用二进制编码的格式进行数据传输；增加传输效率；更加安全可靠；
• 多路复用：基于二进制分帧，可以同时发送帧，而接收方也不需要按照顺序接收，而是等接收完成后通过数据流标识符和序号将他们组合起来；避免了HTTP层对头阻塞，极大提高效率；但还是有TCP层的队头阻塞
• 服务端推送：服务端可以主动推送资源给客户端，避免客户端花过多的时间逐个请求资源，这样可以降低整个请求的响应时间；

3.0

HTTP2.0的缺点就是TCP的缺点

• TCP连接延迟
• TCP队头阻塞问题：某个数据包丢失，后面的必须等前边的超时重传完成

HTTP3把 HTTP 传输层的 TCP 协议改成了 UDP，基于 UDP 的 QUIC协议 可以实现类似 TCP 的可靠性传输。

UDP如何自改可靠：模仿TCP，但从应用层去控制（提供确认机制+超时重传）

HTTP&HTTPS

• http明文传输，存在安全风险；https加安全协议，加密传输
• http三次握手；https还要SSL/TLS握手
• http端口 80；https端口 443
• https协议向CA认证，服务器可信

输入一个URL会发生什么

1. 解析域名 通过DNS将域名转换成IP地址（DNS解析过程）
2. 浏览器自动将地址栏中输入的字符串 转换成 HTTP请求编码，也就是加上请求方式、HTTP版本号、请求头信息等等
3. 浏览器与Web服务器建立一个TCP连接（三次握手）
4. 浏览器发送一个HTTP请求
5. 服务器端处理HTTP请求并响应结果给浏览器（MVC流程）
6. 关闭TCP连接（四次挥手），浏览器展现页面数据

HTTPS加密过程

HTTPS采用混合加密（对称+非对称）；

在建立连接时非对称，建立后是对称

1. 客户端向服务端发送加密通信请求，包括SSL/TSL版本号
2. 确认SSL/TSL版本号，向客户端响应
3. 服务器向客户端发送数字认证。服务器把公钥注册到CA（第三方证书机构），CA拿私钥对公钥处理并颁发数字证书
4. 服务端把公钥发给客户端
5. 服务端发送Hello Done，表示发送完毕
6. 客户端确认数字证书和公钥，向服务端发送公钥加密的预主秘钥
7. 服务端收到后，使用私钥解密；
8. 客户端和服务端都能计算出会话秘钥，以后通过会话秘钥对称加密通信

HTTP协议中缓存的处理流程

客户端中的缓存 过期了，不会立即抛弃。

在下一次发起请求的时候，发现请求过期，会携带着这些过期的缓存信息（摘要）发给服务端，服务端判断缓存的新鲜度，如果数据没有改变，只需返回一个304；如果改变，就将新的数据返回给客户端，客户端更新缓存。

DNS解析过程

1. 浏览器先在自己缓存中查找
2. 浏览器在操作系统缓存中查找
3. 请求本地域名服务器（一般在本地城市）
4. 跳到Root Server 域名服务器请求解析
5. 根据域名返回给浏览器对应的IP和TTL值
6. 并在本地缓存，TTL值由浏览器缓存在本地系统

HTTP长链接优缺点

1. 减少TCP 握手次数
2. 减少慢启动影响

HTTP状态码

• 1**：提示信息，正在协议处理的中间状态
• 2**：请求被成功处理
  • 200：响应头有body数据
  • 204：没有body数据
  • 206：body是部分资源
• 3**：重定向，资源位置改动
  • 301：永久重定向
  • 302：临时
  • 304：缓存重定向
• 4**：客户端请求报文错误
  • 400：请求报文错误
  • 403：服务器禁止访问资源，并不是客户端的请求出错
  • 404：资源在服务器未找到
• 5**：服务器处理请求时内部出错
  • 500：笼统通用的错误码
  • 501：暂不支持该功能（即将开业）
  • 502：自身正常，代理的后端服务出现错误
  • 503：服务器忙，暂时无法响应

跨域

TCP

特点

• TCP 是面向连接的运输层协议
• 点对点，每一条 TCP 连接只能有两个端点
• 使用流量控制和拥塞控制进行可靠传输
• 面向字节流
• 开销大

TCP 和 UDP 的区别？

• TCP 面向连接；UDP 是无连接的，即发送数据之前不需要建立连接。
• TCP 提供可靠的服务；UDP 不保证可靠的
• TCP 面向字节流；UDP 是面向报文的
• TCP点到点连接；UDP 支持一对一、一对多、多对一和多对多的通信方式
• TCP 首部开销 20 字节；UDP 首部开销只有 8 个字节
• TCP用于文件传输、HTTP协议；UDP传视频、音频
• TCP（HTTP,FTP,SMTP）；UDP（DNS,TFTP,NFS）

三次握手

发送端接收端开始状态都为closed

• 第一次握手：客户端请求建立连接，向服务端发送同步报文，进入同步已发送状态，等待服务端确认
• 第二次握手：服务端接收到请求连接报文后，向客户端发送同步确认报文，服务端进入同步已收到状态
• 第三次握手：客户端收到服务端的确认后，向服务端发送确认报文，服务端收到后双方进入连接状态，至此三次握手结束，然后可以进行数据传输

一定是三次？

为什么不能是两次

第一次：服务端确认客户端的发送能力
第二次：客户端确认自己发送能力、服务端的接收能力、服务端的发送能力
但此时服务端不能确认自己的发送能力和客户端的接收能力，所以要再次握手

并且防止已失效的连接请求报文段突然又传输到了服务端，让服务器错误打开连接

为什么不是四次

四次挥手的主要是为了能让TCP连接进入一个半关闭状态，这个状态可以单方面发送，而建立连接的时候不允许出现这种状态

最后一次确认报文丢失

服务端：认为客户端没有接收到第二次握手中的同步确认报文，会超时重传；重发一定次数后，会断开此次连接

客户端：认为连接已经建立，向服务端发送数据，服务端返回一个RST包让客户端知道第三次握手失败。

四次挥手

• 第一次挥手：客户端向服务端发送连接释放报文，主动关闭连接，等待服务器的确认
• 第二次挥手：服务端接收到报文，响应确认报文，进入close-wait状态。TCP连接进入半关闭状态，表示客户端已不再向服务端发数据，但服务端可以给客户端发数据。
• 第三次挥手：服务端向客户端发送释放报文，主动关闭连接，等待客户端确认
• 第四次挥手：客户端收到服务端的释放报文，发出确认报文。客户端进入time-wait状态，经过2MSL后进入CLOSE状态；服务端接收到确认报文后直接进入CLOSE状态。

为什么是四次挥手

关闭连接时，当 Server 端收到 Client 端发出的连接释放报文时，不会立即断开连接，只有等到 Server 端所有的数据都发送完了，这时 Server 端才能发送连接释放报文，之后两边才会真正地断开连接

time-wait状态

2MSL：最长报文段寿命 （约四分钟）

• 保证确认应答报文ACK能够到达服务端，使服务端能够正常关闭连接。第四次挥手，客户端的ACK不一定到达服务端，服务端就会超时重传释放报文，此时如果客户端断开连接，服务端就收不到客户端的确认报文，无法断开连接
• 防止上一次连接中的包失效后重新连接，占用资源；2MSL就会消失

time-wait状态过多

对于服务端，消耗服务端的资源，导致其他请求连接不上

对于客户端，导致端口被占用，占满了就无法进行TCP连接

所以应尽量让客户端主动断开连接，这样time-wait就在客户端；通过调节参数（etc/sysctl.conf）可以让其立即释放

close-wait状态过多

客户端发来断开请求，服务端正在忙着写，没有关闭连接

首先需要考虑程序是否有BUG，导致服务器不能close()

TCP如何保证可靠传输

1. 连接管理：三次握手、四次挥手
2. 校验和：发送方计算数据段校验和并填充，接收方收到数据求校验和并与发送方比对
3. 确认应答与序列号：接收方收到消息回馈ACK报文，其中带有数据的序列号，告诉发送方接受了哪些数据
4. 超时重传：没有接收到ACK报文有两个原因：①接收方没收到数据②ACK报文丢失。接收方再次向发送方发送数据，判断序列号是否重复
5. 流量控制
6. 拥塞控制

流量控制

如果发送速率过快接收方没有能力接收，就会丢包浪费网络资源

接方不断告诉发送方自己的接收能力（窗口剩余大小），发送方调整自己的可发送窗口大小；使用滑动窗口机制来维持动态平衡；

这种窗口机制累计发送和累计应答；之前每发送一个数据包，都会等待ACK，发送效率低，大部分时间都要等待；只要处于可发送窗口内的数据包无须等待，发就完事；之后根据序列号来对未应答的数据超时重传

发送窗口

发送窗口是操作系统开辟的一个缓冲区，发数据就往缓冲区写数据，收到了接收方的ACK后就删除数据（移动指针），由三个指针维护出四个区域：23组成窗口

1. 已经收到ACK包；应答完成，可以被覆盖
2. 发送了但未收到ACK包；
3. 可以发送但未发送的数据；在接收方处理范围之内的
4. 不允许发送的数据；排队等待；超过接收方处理范围

接收窗口

同样是操作系统开辟的缓冲区，接收数据就写入，应用读取后就删除，两个指针维护出三个区域

1. 接收并确认的数据；可以被覆盖
2. 未接收但可以接收的数据；（接收能力）
3. 不能接收的数据；排队等待

发送窗口不能大于接收窗口大小；约等于

拥塞控制

发送端开始发送数据的时候，如果刚开始就发送大量的数据，那么就可能造成 网络堵塞–>丢包–>超时重传–>影响效率

所以TCP引入了慢启动的机制（慢开始），开始发送数据时，先发送少量的数据探路（网络状况）；后每次收到ACK改变拥塞窗口的大小+1；

拥塞窗口先指数增长，过了某个阈值线性增长（拥塞避免）
出现网络阻塞阈值减半，窗口置1

个别报文丢失，会误认为网络出现拥塞，窗口置1，降低传输效率；使用快速重传让发送方尽早知道是报文丢失而不是拥塞；

使用窗口不置1，而是减半，不使用慢开始，而是快速恢复的方式，加快效率

流量控制和拥塞控制

• 流量控制：如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失
• 拥塞控制：拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载

区别

• 流量控制是为了预防拥塞。如：在马路上行车，交警跟红绿灯是流量控制，当发生拥塞时，如何进行疏散，是拥塞控制。
• 流量控制指点对点通信量的控制。而拥塞控制是全局性的，涉及到所有的主机和降低网络性能的因素。

一台机器能连多少TCP？最大并发连接数

客户端

一台客户端有65536个端口，除去0就有65535个连接；

实际上要去除默认占用的端口

服务端

系统通过一个四元组表示一个TCP连接，即双方的 IP +Port

服务端只需要考虑 四元组中客户端的IP和Port，对于IPV4，就有2的32次方（ip数） ×2的16次方（端口数）个； 最大连接数就是2的48次方

但是Linux下限制连接数的主要因素为 内存和允许的FD数量；我们可以通过虚拟内存或修改配置来提升连接数量

路由器&交换机

路由器可以自动分配局域网IP，在网络层，可以处理TCP/IP协议；提供防火墙服务

交换机不行，交换机在中继层；不提供防火墙

对称加密&非对称加密

• 对称加密：加密解密用同样的秘钥。服务端将秘钥发给我，我使用该秘钥加密，发送信息给服务端，服务端用秘钥解密；效率高，安全性较低（秘钥传输容易被窃取）
• 非对称加密：它需要生成一对密钥，公钥和私钥；公钥任何请求都能得到，私钥只由一方保管；向银行请求公钥，银行将公钥发给你，你使用公钥加密，而解密需要银行单方面持有的私钥，不将私钥发出，提升安全性。

syn泛洪攻击

利用TCP协议缺陷，通过发送大量的半连接请求，耗费服务器CPU和内存资源；也就是向客户端短时间伪造不存在的ip进行请求连接，服务端第二次握手向客户端返回报文找不到ip，就一直重试，就会将服务端资源耗尽

防范

1. 防火墙、网关过滤
2. 减少等待时间
3. SYN cookies技术