计算机网络基础

1 OSI和TCP/IP各层的结构和功能

应用层：
通过应用进程之间的交互完成特定的网路任务，应用层协议有：

域名系统DNS
将域名和IP地址映射
在浏览器输入域名，通过DNS解析出真实的IP地址才能访问

超文本传输协议HTTP
传输文本，图片，音视频...

...

将应用层的数据单元称为报文

运输层：
运输层主要任务是负责向两个进程之间提供数据传输服务

运输层主要有:
TCP(传输控制协议): 提供面向连接的，可靠的数据传输服务

UDP(用户数据协议): 提供无连接的，不保证数据传输可靠性的服务

网络层：
网络层主要任务是选择合适的网间路由和交换节点，确保数据及时传送

在TCP/IP体系中，网络层采用IP协议

链路层：
链路层将IP数据报组装成帧

物理层：
物理层用来实现相邻计算机节点之间比特流的传送

2 TCP三次握手/四次挥手

2.1 三次握手

TCP采用三次握手为了将数据准确无误的送到目标处

第一次握手：客户端发送带有SYN标志的数据包到服务器
第二次握手：服务器发送带有SYN/ACK标志的数据包到客户端
第三次握手：客户端发送带有ACK标志的数据报到服务器

SYN: 同步标志 想要建立连接
ACK: 确认标志
FIN: 完成标志 表示没有数据发送了

2.1.1 为什么需要三次握手

三次握手是为了建立可靠的通信信道，三次握手的主要目的就是双方都能确认自己与对方的收发是正常的

第一次握手：客户端向服务器发送带SYN标志数据包
此时服务器能确认客户端的发送功能是正常的，自己的接收功能是正常的

第二次握手：服务器向客户端发送带SYN/ACK标志的数据包
此时客户端确认了自己的发送，接受功能正常 对方发送，接收正常
服务器确认了对方的发送正常，自己的接收正常

第三次握手：客户端向服务器发送带ACK标志的数据包
此时客户端确认了自己的发送，接受功能正常 对方发送，接收正常
服务器确认了自己发送接收正常，对方发送接收正常 

三次握手能确认双方收发都正常，缺一不可

2.1.2 第二次握手回传了ACK，为什么还要回传SYN

ACK是为了告诉客户端，我收到你的信息了
SYN是告诉客户端，想建立服务器到客户端的连接

2.2 四次挥手

断开一个TCP连接需要四次挥手：

第一次挥手: 客户端发送一个FIN标志
第二次挥手: 服务端收到FIN后发送一个ACK标志
第三次挥手: 服务端发送一个FIN标志
第四次挥手: 客户端回传一个ACK标志

示例：A与B通话，A想结束了，告诉B，我说完了(第一次挥手 客户端发送FIN)
B听到后，说我知道了(第二次挥手 服务端发送ACK)
但此时A不知道B还有没有话要将，所以不能直接挂电话
等到B说我也说完了(第三次挥手 服务端发送FIN)
A听到后，说知道了(第四次挥手 客户端发送ACK)
这样整个连接才能结束

2.3 TIME_WAIT和CLOSE状态

CLOSE: 初始状态，表示TCOP连接是“关闭着的”或“未打开的”

TIME_WAIT: 回看4次挥手断开连接的过程
如果此时由客户端先向服务端发送FIN 服务端向客户端发送ACK
接着收到来自服务端的FIN，客户端发送ACK之后会处于TIME_WAIT状态

TIME_WAIT的作用:
1，最后一次ACK是由主动断开连接的一方发出的 如果这个ACK丢失
对方会重发FIN请求，因此在收主动关闭连接的一端，需要维护TIME_WAIT状态
去处理对方重发的FIN请求 

2，由于TCP报文可能会延迟到达，为了避免延迟到达的TCP报文被认为是新TCP连接发来的数据
需要在重新创建TCP连接之前，保持一个不可用的状态，等待可能的延迟报文
一般设置为2MSL(报文在网络中最大生存时间)来解决

当存在大量的短连接时，可能出现很多TIME_WAIT状态的端口，将占用大量的端口，使新建的TCP连接出错，为了避免这样的状况可以缩短MSL的时间

3 TCP和UDP的区别

TCP: 面向连接，传输可靠
传送数据前需要先建立连接，结束后需要断开连接
由于要建立可靠的连接，为此需要三次握手
而在数据传递时，有确认，窗口，重传，拥塞等机制，会增加很多开销
TCP一般用于文件传输，收发邮件，远程登录等0容错的场景

UDP: 面向无连接 传输不可靠
发送方直接发送 接收方直接接收
虽然UDP不可靠，但在语音，视频，直播等能忍受错误的即时通讯场景中非常有效

4 TCP如何保证可靠传输

1，校验和: TCP将保存首部和数据的校验和 
当接收端收到后 进行计算 如果与报文中保存的校验和不一致 
将会将这个报文丢弃 并不会确认收到

2，流量控制: TCP连接的每一方都有固定大小的缓冲区
TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据
当接收方来不及处理发送方的数据，能提示发送方降低发送速率
TCP使用的流量控制协议是可变大小到的滑动窗口协议

3，拥塞控制: 当网络拥塞时，发送方减少数据的发送

4，ARQ协议: 每发完一个分组停止发送 等待接收方确认 收到确认后再发下一个分组

5，超时重传: TCP发出一个分组后 启动一个定时器 等待收到这个报文的确认
如果不能及时收到，则会重新发送

4.1 ARQ协议

ARQ(自动重传请求): 使用超时和确认两个机制，完成可靠的信息传输
如果发送方在发送后一段时间没有收到确认帧，发送方就会重新发送

4.2 滑动窗口和流量控制

TCP利用滑动窗口实现流量控制，流量控制是为了控制发送方发送速率
保证接收方来得及接收 

接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小
从而影响发送方的发送速率，将窗口字段设为0，发送方就不能发送数据

4.3 拥塞控制(4种算法)

拥塞控制: 防止过多的数据注入到网络中，使得网络中的路由器和链路过载
拥塞控制是一个全局性的过程，涉及所有主机，所有路由器，以及与降低网络传输性能的所有因素

流量控制: 是点对点的通信量的控制，流量控制往往抑制发送端发送数据的速率

TCP拥塞控制的四种算法:

为了进行拥塞控制，TCP发送方要维持一个拥塞窗口(cwnd)的状态变量，初始值为1
拥塞窗口的大小取决于网络的拥塞程度，且动态变化
发送方让自己的发送窗口取为拥塞窗口和接收方的拥塞窗口中较小的一个

1，慢开始: 慢开始的思路是当主机开始发送数据时，如果立刻发送大量数据到网络中
可能会引起网络拥塞，因为此时还不知道网络的拥塞状况，较好的方法是先探测一下
即由小到大增大发送窗口，即由小到大增大拥塞窗口数值

2，拥塞避免: 思路是让拥塞窗口缓慢变大，每经过一个往返时间cwnd的值+1

3，快重传/快恢复(FRR): 能快速恢复丢失的数据包 
如果接收方收到了一个不按顺序的数据段，会立刻发给发送端一个重复确认
如果发送方收到了三个重复确认 接收方假定这些数据段丢失了 并立刻重传这些数据段
有了FRR 就减少了采用定时器重传要求的等待时间

5 TCP粘包和拆包

5.1 TCP粘包和原因

TCP粘包：指发送方的若干数据包在到达接收方时粘到了一起
从接收方缓冲区看，后一包的首部紧连着前一包的尾部

TCP粘包原因
发送端:
1，要发送的数据小于TCP的缓冲区大小，TCP将多次写入缓冲区的数据一次发送出去

2，TCP默认使用Nagle算法，Nagle算法可能造成粘包
Nagle算法的作用: 减少网络中报文段的数量

Nagle算法的机制: 只有上一个分组得到确认，才发送下一个分组
				收集多个小分组，在一个确认到达时一起发送

接收端:
1，接收端没有及时读取缓冲区中的数据

5.2 什么时候处理粘包，如何处理

什么时候该处理粘包:
如果粘包的多组数据是同一块数据的不同部分，可以不处理
如果多个分组毫无关系，则需要处理

如何处理:
发送方-> 可以关闭Nagle算法

接受方-> 接收方没有办法处理，只能交给应用层来解决
应用层解决可以通过循环处理的方式，应用程序从缓冲区中读数据时
读完一条立刻读下一条，只需给每个数据加上开始和结束标志

5.3 UDP有无粘包

TCP是基于流的传输，而UDP是面向消息传输
UDP一次只接受一条独立的消息，不会发生粘包

6 HTTP协议

6.1 在地址栏输入url到显示页面的过程

1，DNS解析 浏览器查找域名的IP地址

2，TCP连接

3，发送HTTP请求

4，服务器处理请求并返回HTTP报文

5，浏览器解析HTTP报文并渲染页面

6，断开连接

6.2 状态码

常见的状态码：

100 继续
200 成功
404 无法找到
500 服务器内部错误

6.3 HTTP的长连接和短连接

在HTTP1.0中默认使用短连接，及客户端和服务端每次的HTTP操作，都先建立好连接，任务结束后立刻断开，当访问一个Web页面中有许多Web资源(音视频图，CSS文件，JS文件)时，访问每个资源都需要建立一次连接并结束

而从HTTP1.1开始，默认使用长连接，当一个网页打开后，客户端和服务器用于传输数据的TCP连接不会关闭，但不是一直连接着的，有一个保持时间

HTTP协议的长连接和短连接，本质上是TCP的长连接和短连接

6.4 HTTP是无状态的，但怎么保存用户状态

HTTP协议自身不保存请求和响应的通信状态，但在某些场景下需要保存用户的状态

为此使用Session机制，Session的主要作用就是通过服务端记录用户的状态
典型的场景就是购物车，当要添加商品到购物车时，系统不知道是哪个用户操作的，因为HTTP协议不保存用户信息，而有了Session后就可以标记并跟踪这个用户

在服务端保存Session的方式有很多，大部分情况都是在Cookie中附加一个Session ID来跟踪
如果Cookie被禁用了，可以利用URL直接把Session ID加在URL路径后面

6.5 Cookie和Session的区别

Cookie和Session都是用来跟踪用户身份的，只是应用场景不同

Cookie一般用来保存用户信息
如登录一个网站后，之后可以直接访问，不需要重新登录

Session用于通过服务端记录用户状态
当要添加商品到购物车时，服务器不知道是哪个用户操作的
因为HTTP是无状态的，服务端根据给用户创建的Session之后就可以标识这个用户

Cookie数据保存在客户端，Session数据保存在服务端

6.6 HTTP1.0和HTTP1.1的主要区别

1，长连接: 在HTTP1.0中默认使用短连接
HTTP1.1起默认使用长连接

2，错误状态响应码: 在HTTP1.1中新增了24个错误状态响应码
如409(请求的资源与当前资源发生了冲突) 410(某个资源已被永久删除)

3，缓存处理: HTTP1.1引入了更多缓存控制策略

6.7 HTTP和HTTPS的区别

1，端口: HTTP采用80端口 HTTPS采用443端口

2，安全性: HTTP传输的都是明文 不安全 可能被篡改
HTTPS的内容经过加密 安全

3，资源消耗: 由于HTTPS提供了加密的功能
因此HTTPS比HTTP消耗更多服务器资源

6.8 URL和URI

URI: 统一资源标志符
可以唯一标志一个资源

URL: 统一资源定位符
可以提供该资源的路径

URI的作用类似于身份证号，URL作用类似于家庭地址
URL是更具体的URI，它不仅唯一标识资源，还提供了该资源的路径信息