计算机网络基础知识 学习笔记

从浏览器输入一个url中间经历的进程

1. 中间涉及了那些过程
2. 包含了那些网络协议
3. 每个协议都干了什么

1：解析是那个协议->判断是ip地址还是域名->DNS缓存（浏览器缓存、host文件）->DNS查询->TCP握手->HTTP请求->反向代理nginx->uwsgi/gunicorn->web-app响应->TCP挥手
2：这个过程会从应用层（Http协议、Https协议）-传输层（TCP协议）-网络层（ARP协议，IP协议，ICMP协议）-数据链路层-物理层。
3：应用层：

1. Http协议：HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据
2. Https协议：基本沿用http协议，只是在http和tcp之中加多一层tls/ssl协议，位于应用层和传输层的安全套接层，
   https主要有几个特性，机密性、完整性、身份认证和不可否认。机密性由对称加密、非对称加密或者两个混合一起、完整性靠摘要算法。身份认证和不可否认就靠数字签名（私钥加密，公钥再解密）

传输层：

1. TCP协议：提供全双工通信，确保可靠交付的服务

网络层：
注：ARP协议为IP协议提供服务，IP协议为ICMP协议提供服务

1. ARP协议：通过广播把IP地址解析成mac地址
2. IP协议：IP可以根据数据包包头中包括的目的地址将数据包传送到目的地址，在此过程中IP负责选择传送的道路，这种选择道路称为路由功能。
3. ICMP协议:确认IP包是否成功到达目标地址,报告在发送过程中IP包被丢弃的原因

TCP三次握手

1. 客户端发送一个SYN包给服务端
2. 服务端返回一个SYN/ACK应答报，表示服务器接收连接
3. 客户端再发会一个ACK应答包，并进入连接状态（ESTABLISHED）
4. 服务端收到这个应答包后也进入连接状态

TCP状态

1. LISTENING：监听状态
2. ESTABLISHED：表示建立连接，正在通信
3. CLOSE_WAIT：对方主动关闭连接或者网络异常导致连接中断，这时我方的状态会变成CLOSE_WAIT 此时我方要调用close()来使得连接正确关闭
4. TIME_WAIT：我方主动调用close()断开连接，收到对方确认后状态变为TIME_WAIT，TIME_WAIT状态会一直持续2MSL(即两倍的分 段最大生存期)，以此来确保旧的连接状态不会对新连接产生影响。
5. SYN_SENT：请求连接状态

TCP握手为什么不能两次

答：TCP握手两次可能会出现死锁的情况，当服务端发送回应答报文后，若是两次握手，那么服务端此刻进入了ESTABLISHED的连接状态，可以发送数据给客户端，但是当这个应答报文中途丢失，客户端并没有接收到这个报文，就会发送没收到报文给服务端，而服务端发送的数据被客户端一直认为是错误的，服务端也因为看到客户端发来的丢失报文以为是发送数据错误而一直重复发送。

幂等和安全性

幂等：多次请求结果是一样的
安全性：对服务器是否有改变

tcp 怎么保证数据包有序

答：这与tcp首部报文段中的序号、确认号、确认ACK和数据报长度，tcp连接中的字节流的每一个字节都是按顺序编号的，序号表示本次数据报名第一个字节的序号，确认号表示这次发送后得到的应答的第一个数据字节序号，确认ACK表示0时确认号字段无用，1时确认号有用，数据长度就是本次发送数据的长度，因此，当发送一次数据的时候，应答端根据序号和数据长度加起来计算出下一个请求发来的数据起始号，也根据请求端得到的确认号来依据发送数据。

TCP什么时候发送复位包

答：

1. 往不存在的端口发送数据
2. 异常终止连接
3. 处于半打开的连接状态
   详解

TCP心跳包机制

答：

1. 根据情况自己设定发送的时间，短可以5-6s，长可以几分钟等
2. 给对方发送一个心跳包，并同时设置一个超时计数器
3. 若超时时间内接受到返回的确认报，那表示连接正常
4. 超时时间内没有收到确认报，认为已断开连接，关闭连接

tcp 和 udp 的异同

答：tcp是面向连接的、点对点的、可靠支付、面向字节流、提供全双工通信的、首部开销大（20字节）
udp是面向无连接的，尽最大努力交付的，面向报文、没有拥塞机制，首部开销大（8字节）

tcp 怎么保证可靠性

答：确认丢失和确认迟到机制
确认丢失指在设定的超时重传的时间内没有收到确认，就认为字节发送的分组出错，重新发送，应答端此时接收到这个报文，重复接收就丢弃不处理，不重复就向上传输，但是都要发送确认报文。发送方也一样

tcp中拥塞避免和流量控制机制

答：流量控制：利用滑动窗口来进行限制，A向B发送数据，在建立连接时，B告诉A我的接收窗口rwnd=400，告诉发送方可以发送的总数据字节的长度，从而实现流量控制，当为0的时候就不能再发送了。
拥塞机制的原因：我们知道TCP通过一个定时器（timer）采样了RTT并计算RTO，但是，如果网络上的延时突然增加，那么，TCP对这个事做出的应对只有重传数据，然而重传会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这就导致了恶性循环，最终形成“网络风暴” —— TCP的拥塞控制机制就是用于应对这种情况。
拥塞避免：有四个部分算法，慢开始、拥塞避免、快重传和快恢复。慢开始表示当初始拥塞窗口比慢开始门限小的时候，每次发送完成，拥塞窗口就加1，从而使得拥塞窗口成指数增长，当增长到的慢开始门型后就变成拥塞避免机制了，按线性规律去增长，当增到有出现超时的情况的时候，发送方判断为网络拥塞，就会调整门限值为当前的拥塞窗口的一半，然后再重开时。有时候网络并没有拥塞，但是却丢失了个别的报文表，发送方收到了重复确认的报文段，就会使用快重传的算法，要求接收方不会发送数据的时候才携带确认回复，而是一接受到数据就立马发送确认，发送方收到连续3个重复确认，就立马回进行快重传，重新发送数据，也开始启动快恢复算法，拥塞窗口降到当前的一般，并开始拥塞避免算法进行发送。

TCP四次挥手的详细解释

答：A发送断开连接请求，进入终止等待状态，B接受到请求，发送收到确认，进入关闭等待状态，此时处于半关闭（close_wait）状态，A没有数据发给B，但是B可以发送给A数据，A收到B的确认后，就进入终止等待（half_close）的状态，等B处理完所有的数据，就发送连接释放报文给A，进入最后确认状态，A收到后发送确认，进入时间等待状态，B收到确认后就关闭连接，A等待2个MSL时间后没有收到重传就关闭连接了。

TCP挥手为什么不能是三次

答：TCP三次挥手，那么在第三次的时候，即客户端（主动挥手的一方）会进入time_wait状态，这个时候服务端有可能还有数据要继续发送给客户端，而客户端已经进入了拒绝状态，就无法处理这些服务端还没有来得及发送的数据。

四次挥手之后为什么还要等待2msl

答：一个报文的最大存活时间，确保服务端的确收到了客户端的确认报文

滑动窗口机制的原理和理解

答：可以连续发送报文而不需要等待确认报文到达，接收方接收到会把滑动窗口往后滑动，如果发送方有一个报文缺失，接收方接受到下一个报文会重复发送这个缺失的报文，直到接受到这个报文。若接收方接受到的报文其中一个缺失了，但是下一个报文收到了，就不会重复发送。因此很大一个缺点就是浪费，后面正确的报文没有缓存，也有选择重传机制，保留收到的报文到缓冲区，但是会导致乱序，因此需要排序

什么是长链接

答：从HTTP/1.1开始默认使用长连接。使用长连接的HTTP协议会在响应头加入Connection: keep-alive。当打开一个网页客户端和服务端建立的TCP连接不会关闭。当再次访问服务器时还会使用这个连接。

cookie和session的区别

1. session一般是服务器生成之后给服务端（通过url参数和cookie）
2. cookie是实现session的一种机制，通过Http的cookie实现
3. session是通过在服务器保存sessionid识别用户，cookie存储在客户端
4. session的保存时间是-1,关闭页面就会消失

time_wait过多的问题

答：time_wait产生的原因是主动方发起TCP挥手的一方在最后发送确认报文后进入的状态，这个状态下依然保存了TCP连接的四元组，导致占用端口不可用，而过多将会导致很多端口不可用，占用太多资源，因此可以设置SO_REUSEADDR来让端口可以重用，对于出于time_wait状态的端口可以使用。

Http和Https区别

1. 在Http与TCP直接再加一层SSL/TLS
2. 用于对请求数据的加密，在使用Http的时候我们抓取报文是可以看到数据的，但是使用Http的时候我们抓取的报文是加密过的，在我们眼中看起来就是毫无规律的乱码
3. 客户端和服务器都支持很多密码套件，如ECDHE-RSA-AES256-GCM-SHA384，是一种固定的格式：“密钥交换算法+签名算法+对称加密算法-摘要算法“，意思就是握手的时候使用ECDHE算法进行密钥交换，用RSA签名和身份认证，握手后的通信使用AES对称算法，密钥长度256位，分组模式（把固定长度的密钥加密成密文）是GCM，摘要算法SHA384用于消息认证和产生随机数
4. 通信安全的四大定义：机密性、完整性、身份认证和不可否认。机密性由对称加密和非对称加密混合加密来保证，完整性由摘要算法来保证，身份认证和不可否认就由数字签名来保证（私钥加摘要算法来实现）
5. 因为多了一层SSL握手，Https比Http会更耗时

如何安全的交换私钥

1. 服务端向证书机构发送公钥，证书机构利用自己的私钥加密公钥，并通过服务器的网址生成证书签名，再通过私钥加密证书签名生成证书发给服务器
2. 客户端请求服务端，获取证书，用浏览器或者本地已经存储的根证书验证证书的真假，找到这个证书机构的公钥来解密获得服务端的公钥
3. 客户端对称加密生成自己的私钥，再通过获得的公钥加密，发给服务端，服务端用私钥解密就可以获取客户端的私钥，接下来就安全的交换了私钥，并进行加密通信了。

注：就算黑客自己也申请了证书并截取了服务端的证书，伪造假证书发给客户端，但是证书的生成过程包括了网址等信息，很容易验证出是非法来源。