开发学习笔记-计算机网络

计算机网络学习笔记

1.网络传输模型层次结构
https://www.cnblogs.com/dadadechengzi/p/7999371.html
用户层
直接向用户提供服务，负责提供一些登陆验证、ip地址分析、数据加密解密、压缩和解压缩、数据编码等服务，将数据向下传送给传输层传输给目标进程
传输层(进程-进程 逻辑传输)
接收用户层传来的数据，并划分为一个个数据段，向下传送给网络层。
对于用户层而言，传输层屏蔽了下面的层次信息，提供透明的传输服务，用户层认为数据是通过传输层直接传送到目标进程的。
网络层(主机-主机 逻辑传输)
接收传输层传来的数据段，并封装为数据包，向下传送给数据链路层。
网络层将ip地址信息转换为主机的物理地址信息(ARP协议)，并封装到数据包中，由此寻找路由，传输数据包
数据链路层
接收网络层传来的数据包，并封装为数据帧，向下传送给物理层，进行传输，提供差错检测、流量控制等
数据链路层在相邻节点间建立数据链路
物理层
网络传输的物理设备，比特流在这些物理设备上传输到目标。传输的单位是比特，传输的是比特流

2.三次握手
第一次握手
客户端向服务端发起请求，置SYN=1， seq=J，将这个数据包发送给服务端，等待服务端确认
第二次握手
服务端收到客户端的数据包，由SYN=1知道是发起连接的请求，服务端将SYN和ACK都置1，ack=J+1，seq=K，发送给客户端
第三次握手
客户端收到服务端的数据包，检查ack是否为J+1，ACK是否为1，如果是则令ack=K+1，返回给服务端，服务端再检查ack是否为k+1，ACK是否为1，如果是则连接建立成功

3.四次挥手
第一次挥手
客户端向服务端发送一个FIN，值为M，表示请求关闭连接
第二次挥手
服务端收到客户端发送的数据包后，由FIN的值发现请求关闭连接，发送ack=M+1给客户端，表示同意关闭连接，此时连接处于半关闭的状态。客户端的连接关闭
客户端不再有数据发送给服务端，但服务端如果有需要发送的数据，客户端仍要接收
第三次挥手
服务端发送完数据后，向客户端发送一个FIN，值为K，用来关闭服务端到客户端的数据传送
第四次挥手
客户端接收到数据包后，发送ack=K+1给服务端，表示关闭连接，服务端的连接关闭。

4.TCP流量控制和拥塞控制
流量控制是端到端的控制行为，拥塞控制是全局的控制行为
流量控制
数据接收端维护一个窗口，进行流量控制，每次收到数据后返回的确认数据包中包含当前窗口剩余空间大小，数据发送端根据窗口大小计算还能发送多少个数据
进行流量控制，避免发送端发送过快，接收端接收速度慢而导致数据丢失等问题
拥塞控制
如果在某一个时间段，网络中对某一资源的需求过大，就会导致该资源处的拥塞，导致网络性能下降，拥塞控制就是防止有过多的数据涌入网络中，造成网络资源和链路负担重。
慢开始
发送端维护一个拥塞窗口(发送窗口)，拥塞窗口表示能发送的数据量的大小
在慢开始阶段，拥塞窗口初始大小为1，每当收到所有发送数据的确认报文后(一个往返时间RTT)，就将拥塞窗口大小翻倍
当拥塞窗口大小 大于 ssthresh后，就进入拥塞避免阶段
拥塞避免
拥塞避免阶段拥塞窗口的增大不再翻倍，每次只增加1
在慢开始和拥塞避免阶段，一旦判断发生拥塞(在规定时间内收不到指定确认报文)，则将ssthresh值设为当前拥塞窗口大小的一半，并将拥塞窗口大小设置为1，从慢开始重新增长
快重传
快重传要求接收方当收到失序报文后就立即进行重复确认(接收端发送的确认报文中ack=k+，k即为当前收到的数据编号，k+1是期待收到的下一数据的编号)，如果发送端
连续收到三个关于某一数据的确认报文，就确定该数据丢失，但此时不一定网络中发生了拥塞，因为收到报文意味着其他的数据能够成功发送到发送端，有可能只是某一个数据
在网络中丢失了。因此发送端在收到三个重复的确认报文后，不需要等待计时器到达，立即重新发送数据
快恢复
如果发送端连续收到三个关于某一数据的确认报文，就确定该数据丢失，但此时不一定网络中发生了拥塞，因为收到报文意味着其他的数据能够成功发送到发送端，
此时将ssthresh减半，拥塞窗口大小更改为ssthresh，并开始拥塞避免，不再从慢开始开始增加。

5.UDP和TCP的区别，各自的好处
TCP是面向连接的，UDP是无连接的
TCP是可靠的，UDP是不可靠的
TCP只支持点对点的通信，UDP支持一对一，一对多，多对一，多对多的通信
TCP是面向字节流的，UDP是面向报文的
TCP有拥塞控制机制，UDP没有拥塞控制
TCP首部开销比UDP大
TCP能够提供可靠的传输，保证数据的一致性，安全性，但由于拥塞控制、流量控制等，会牺牲一些时间，数据传输有时延
UDP提供不可靠的传输，尽最大努力交付，不在乎网络中是否拥塞等问题，因此时延小，适用于网络直播、网路游戏等应用

6.UDP的工作方式
UDP是传输层协议，提供最基本的服务：复用、分用以及差错检测
UDP提供不可靠的服务
UDP无连接，不存在建立连接需要的时延，不需要维护链接状态的额外开销，在时间和空间上开销都小于TCP
UDP没有拥塞控制，网络拥塞不会影响数据发送速率，适用于对于实时性要求强且可以容忍一些数据丢失，但不允许时延高的应用
UDP提供尽最大努力交付，所有维护传输可靠性的工作需要用户在应用层来完成
UDP是面向报文的，不会对上层传下来的报文拆分或合并，直接添加首部后传给网络层
UDP常用于一次性传输比较少量数据的网络应用，如DNS

7.TCP如何保证可靠性
数据包校验
对接收到数据包先进行校验，如果有则丢弃报文并不响应
重排序
数据包到达的顺序可能不与发送数据一致，TCP提供对失序数据重排序的服务
丢弃重复数据
对于重复数据能够判断并丢弃
应答机制
对收到的数据发送确认，保证发送端知道哪些数据没有成功发送，并重传
超时重发
当发送端发送一个数据后，启动一个计时器，在计时器时间内如果没有收到确认报文，则重传
流量控制
TCP连接的每一方都有固定大小的缓冲空间，TCP接收端只允许发送端发送自己能接纳的数据量

8.HTTP vs HTTPS
超文本传输协议(HTTP): 是一个基于请求与响应，无状态的应用层协议，常基于TCP/IP传输数据，设计初衷是提供一种发布和接收HTML页面的方法
HTTP的连接：基于三次握手
HTTP的缺点： 无连接：服务端响应请求后就断开TCP连接(后期HTTP协议可以有持久连接策略)，如果客户端在短时间内多次请求资源，每次都需要重新响应请求
无协议：协议对客户端没有状态存储，依靠session和cookie来记忆用户信息，否则访问一个网站需要反复登录
通信使用明文、请求和响应不会对通信方进行确认(可能遭遇中间人攻击)，无法保护数据的完整性
HTTP的优点： HTTPS:简单快速、灵活
超文本传输安全协议(HTTPS)：基于HTTP协议，通过SSL或TLS提供加密处理数据、验证对方身份以及数据完整性保护
SSL：安全套接字协议
TLS：安全传输层协议
HTTP的连接(应用层的连接！传输层依然是TCP/IP！！！)：
1.客户端发送请求到服务端，信息：随机值1和支持的加密算法
2.服务端接收请求后响应客户端，信息：随机值2和匹配好的协商加密算法
3.服务端发第二个响应报文给客户端：数字证书。服务端有一套数字证书(自己制作或向组织申请，自己制作的证书需要客户端验证通过才能继续访问)。
发送的数字证书(由权威机构私钥加密，客户端和服务端有权威机构公钥)包括加密后的服务器公钥，还包含了证书的颁发机构，过期时间，数字签名，签名计算方法，服务端的域名信息等
4.客户端解析证书，由客户端的TLS来完成：首先验证公钥是否有效，如果异常则弹窗警告，没有问题则生成一个随机值(预主密钥)
5.客户端认证证书通过后，将随机值1，随机值2和预主密钥组装为会话密钥，再通过证书的公钥加密会话密钥
6.客户端传送加密后的会话密钥给服务端，服务端得到后解析出随机值1，随机值2和预主密钥
7.服务端组装和客户端相同的会话密钥
8.客户端和服务端互相发送一条会话密钥加密的消息，验证对方是否能正常接收，正常接收则SSL层连接建立完成
会话密钥：对称加密 速度快，可加密内容较大，用来加密会话过程中的消息。
公钥私钥：非对称加密 加密速度较慢，但能提供更好的身份认证技术，用来加密对称加密的密钥。
单向认证：客户端认证服务器
双向认证：客户端认证服务器，服务器认证客户端

	如何保证服务器给客户端的是真正的公钥而不是中间人伪造的？怎么保证证书不会被掉包？
	https://zhuanlan.zhihu.com/p/31477508
		客户端验证证书安全性过程：
			1.当客户端收到证书后，使用权威机构的公钥对证书进行解密得到服务端的公钥和证书的数字签名，数字签名经过公钥解密得到证书信息摘要
			2.然后按照签名计算的方法计算一下当前证书的信息摘要，预收到的信息摘要作对比，如果一样，则证书一定是服务器下发的，没有被人篡改。
			  因为中间人即使拥有权威机构的公钥，能够解密证书内容并篡改，但其没有私钥，无法及逆行加密，强行加密会导致客户端无法解密，发现问题。
		中间人也无法把自己伪装成服务器去向权威机构寻求信息，因为无法伪造域名的信息，域名管理邮箱等。
		
	HTTPS比HTTP安全，但安全性有限
		1.HTTPS协议的加密范围有限，对于黑客攻击不起作用
		2.某些国家可以控制CA根证书，可以掌握私钥，出现中间人攻击
		
	HTTPS的缺点：
		1.SSL证书需要购买申请，功能越强，费用越高
		2.增加页面的加载时间近50%，增加耗电
		3.流量成本高
		4.占用更多服务端资源
		5.握手建立连接的阶段耗费时间，影响用户体验(改进方式：分而治之，一部分使用HTTP协议，一部分使用HTTPS)

9.TCP粘包
TCP粘包：多个数据包粘到一起，看起来像一个大的数据包，接收缓冲区中后一包的数据的头紧接着前一包数据的尾
原因：
发送方： Nagle算法自动优化，将多个小数据包合并成一个大数据块并封包发送
接收方： 应用程序从接收缓存中读取数据的速度小于接收的速度，多个包被缓存，可能会出现首尾相接粘在一起的包
处理：
发送方： 关闭Nagle算法
接收方： 交给应用层处理，应用层采取循环处理的方式，循环读取每一条数据。
判断一条数据的方法：
1.格式化数据，每条数据有固定的格式(开始符，结束符)
2.在发送数据时将数据长度一并发送，应用层在处理时根据长度来读取数据
UDP不会产生粘包，因为UDP是面向消息传输，消息有多大，就发送多大的数据包，接收方一次只接收一条消息。