网络基础知识小结
一、Tcp/ip五层网络协议
互联网协议按照功能不同 分为OSI七层模型 或者Tcp/Ip 五层模型 或者 Tcp/ip四层模型
七层网络模型
每层运行常见的物理设备:
网络模型对应的物理设备
我们将应用层、表示层、会话层并做引用层，从Tcp/ip五层模型上来理解每层的由来和作用。
1.1、物理层。
物理层利用电器特性发送高低电平(0、1序列)
-
物理层由来：上面提到，孤立的计算机之间要想一起玩，就必须接入internet，言外之意就是计算机之间必须完成组网
image
- 物理层功能:主要是基于电器特性发送高低电压(电信号),高电压对应数字1，低电压对应数字0
1.2、数据链路层
数据链路层为01序列提供了分组的概念。将数据包分为数据头head和数据data两部分,规定将发送者的mac地址和接收者的mac地址写入数据头中。即以太网协议。
数据链路层，在同一个局域网内,不同主机之间是靠广播进行通信的。
ethernet规定:
一组电信号构成一个数据包，叫做‘帧’
每一数据帧分成:包头head和数据data两部分。
| head | data |
|---|
image
head包含：(固定18个字节)
发送者／源地址，6个字节
接收者／目标地址，6个字节
数据类型，6个字节data包含：(最短46字节，最长1500字节)
数据包的具体内容head长度＋data长度＝最短64字节，最长1518字节，超过最大限制就分片发送
mac地址：
head中包含的源和目标地址由来：ethernet规定接入internet的设备都必须具备网卡，发送端和接收端的地址便是指网卡的地址，即mac地址
mac地址：每块网卡出厂时都被烧制上一个世界唯一的mac地址，长度为48位2进制，通常由12位16进制数表示（前六位是厂商编号，后六位是流水线号）
广播：
有了mac地址，同一网络内的两台主机就可以通信了（一台主机通过arp协议获取另外一台主机的mac地址
ethernet采用最原始的方式，广播的方式进行通信，即计算机通信基本靠吼
1.3、网络层（IP层）
网络层(IP层) 为每台主机赋予了一个虚拟的IP地址,通过这个虚拟的IP地址，可以判断两个主机是否处于同一个广播域:
- 同一广播域的主机间采用广播的方式通信；
- 不同广播域的主机之间采用用路由的方式分发数据包。
网络层由来:有了ethernet、mac地址、广播的发送方式,世界上的计算机就可以互相通信了。
但世界范围的互联网是有一个个彼此隔离的小的局域网组成的，如果所有的通信都采用以太网的广播方式，那么一台机器发送的包全世界都会收到，不仅仅是效率低的问题了，这会是一种灾难。
ip地址分成两部分:网络部分：标识子网;主机部分：标识主机。
ip地址通过与子网掩码做and，来得出子网标识。
ip数据包
ip数据包也分为head和data部分，无须为ip包定义单独的栏位，直接放入以太网包的data部分
head：长度为20到60字节
data：最长为65,515字节。
而以太网数据包的”数据”部分，最长只有1500字节。因此，如果IP数据包超过了1500字节，它就需要分割成几个以太网数据包，分开发送了
| 以太网头 | ip 头 | ip数据 |
|---|
1.4、传输层(Tcp层)
传输层 提出了端口的概念,来区分不同的应用程序。
传输层的由来:
网络层的ip帮我们区分子网，以太网层的mac帮我们找到主机,同一个主机上有多个应用程序。我们通过ip和mac找到了一台特定的主机，如何标识这台主机上的应用程序，答案就是端口。
传输层功能：建立端口到端口的通信
补充：端口范围0-65535，0-1023为系统占用端口
传输层 分为Tcp协议和Udp协议
tcp
| 以太网头 | ip 头 | tcp头 | 数据 |
|---|
udp
| 以太网头 | ip 头 | udp头 | 数据 |
|---|
Tcp头占20个字节,主要信息为源端口号,目的端口号,序列号(seq)、和确认号(ack)
tcp头
Tcp建立连接需要三次握手、Tcp断开连接需要4次挥手。
1.5、应用层(如http)
应用层由来:
用户使用的都是应用程序,均工作与应用层。每个应用程序都会占用一个端口,如http程序占用80端口,https程序占用443端口。
应用层功能:规定应用程序的数据格式。
TCP协议可以为各种各样的程序传递数据，比如Email、WWW、FTP等等。那么，必须有不同协议规定电子邮件、网页、FTP数据的格式，这些应用程序协议就构成了”应用层”。
网络协议示例
二、 Tcp三次握手、四次挥手。
Tcp是面向连接的，安全的传输。
Tcp建立连接需要三次握手,Tcp断开连接需要四次挥手。
2.1、Tcp协议头介绍
tcp协议头
- 序列号(seq):：占4个字节，用来标记数据段的顺序,TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生；给字节编上序号后，就给每一个报文段指派一个序号；列号seq就是这个报文段中的第一个字节的数据编号。
- 确认号ack：占4个字节，期待收到对方下一个报文段的第一个数据字节的序号；序列号表示报文段携带数据的第一个字节的编号；而确认号指的是期望接收到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号。
- 确认ACK:占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效
- 同步SYN,连接建立时用于同步序号。
当SYN=1，ACK=0时表示：这是一个连接请求报文段。同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。
- 终止FIN:用来释放一个连接。
FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接。
2.2、Tcp建立连接 三次握手
三次握手
- 第一次握手：建立连接时，客户端发送syn包到服务器，并进入SYN_SENT状态，等待服务器确认；
- 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
- 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。
2.3、Tcp断开连接 需要四次挥手
四次挥手
当被动方收到主动方的FIN报文通知时，它仅仅表示主动方没有数据再发送给被动方了。但未必被动方所有的数据都完整的发送给了主动方，所以被动方不会马上关闭SOCKET,它可能还需要发送一些数据给主动方后，再发送FIN报文给主动方，告诉主动方同意关闭连接，所以这里的ACK报文和FIN报文多数情况下都是分开发送的。
- （1）第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
- (2)第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。(此时Server端可能还有数据没有完全发送给客户端)
- (3) Server端完成对Client端的所有数据发送之后,会第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
- (4)第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server。注意此时Client端的TCP连接还没有释放，必须经过2*MSL（最长报文段寿命）的时间后，没有收到新的服务端消息,才会结束Tcp连接。
- 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。可以看到，服务器结束TCP连接的时间要比客户端早一些。
2.4、思考题(答案见参考文章2)
- 为什么连接的时候是三次握手，关闭的时候却是四次握手？
- 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
- 为什么不能用两次握手进行连接？
3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。
- 如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。
服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
三、SSL/TLS https四次握手过程
http默认端口号是80，
https默认端口号是443
3.1、Https与Http的区别:
HTTP协议运行在TCP之上，所有传输的内容都是明文。
HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
https与http的区别
3.2、SSL与TLS
SSL ：Secure Socketes Layer 安全套接字协议
TLS:Transport Layer Security 传输层安全，TLS是SSL的替代和升级。
TLS与SSL在传输层与应用层之间对网络连接进行加密。是为网络通信提供安全及数据完整性的一种安全协议。
3.3、SSL/TLS加密过程
ssl握手加密过程
1、client客户端向服务端发送https请求
客户端（通常是浏览器）先向服务器发出加密通信的请求，这一步骤会携带一些信息
- 支持的协议版本，比如TLS 1.0版
- 一个客户端生成的随机数RandomC，稍后用于生成“协商密钥”。
- 支持的加密方法，比如RSA公钥加密。
- 支持的压缩方法。
2、服务器响应
服务器收到客户端请求后，向客户端发出回应，服务器的回应一般包含以下内容
- 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
- 一个服务器生成的随机数RandomS，稍后用于生成“协商密钥”*。
- 客户端支持的加密方法中选择一个作为确认要使用的加密方法，比如RSA公钥加密。
- 服务器证书。 这个服务器证书就是表明服务器身份的东西，其中也包含了非对称加密中需要使用的公钥。
3、客户端证书校验、生成密码、公钥加密
客户端收到服务器回应以后，首先验证服务器返回的证书。如果证书没有问题，客户端就会从证书中取出服务器的公钥。随机生成一个Pre-Mastater Key,用服务器的公钥加密对Pre-Mastater Key进行加密，发送给服务端。
3、客户端生成协商秘钥
- 客户端此时持有三个随机数:RandomC、RandomS和Pre-master,利用上面的三个随机数,通过事先商定的加密方法，生成本次会话所用的“协商密钥”。
- 客户端向服务端发送"编码改变通知"，表示随后的信息都将用双方商定的加密方法和密钥发送。
- 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项通常也是前面发送的所有内容的hash值，用来供服务器校验。
4、服务端私钥解密、解密握手消息、验证Hash
服务器收到客户端公钥加密的第三个随机数Pre-master key之后，通过自身私钥解密该数值并由之前的RandomC和RandomS计算生成本次会话所用的“会话密钥”。然后，通过约定的Hash算法验证客户端发送的数据完整性。
5、服务端发送加密信息S-C
主要是指
- 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
- 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发生的所有内容的hash值，用来供客户端校验.
6、客户端 解密握手消息、验证Hash
客户端解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束。
7、正常加密通信
握手成功之后，所有的通信数据将由之前协商密钥及约定好的算法进行加密解密。
四、http1.0和http2.0的区别
http的主要版本包括:http1.0、http1.1、http2.0
http版本
4.1、http1.1与http1.0的区别
- 长连接(Persistent Connection)
HTTP1.1支持长连接和请求的流水线处理，在一个TCP连接上可以串行地传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。
在HTTP1.1中默认开启长连接keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。HTTP1.0需要使用keep-alive参数来告知服务器端要建立一个长连接。
- 节约带宽:Http1.1 header中支持了range参数,允许仅返回异步分请求的数据。支持了支持断点续传功能
HTTP1.0中存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能。HTTP1.1支持只发送header信息（不带任何body信息），如果服务器认为客户端有权限请求服务器，则返回100，客户端接收到100才开始把请求body发送到服务器；如果返回401，客户端就可以不用发送请求body了节约了带宽。
- HOST域:Http1.1 支持在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址
在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname），HTTP1.0没有host域。随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都支持host域，且请求消息中如果没有host域会报告一个错误（400 Bad Request）。
4.2、Http2.0与http1.1的区别
- 多路复用
HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级
多路复用
- 服务器推送
服务端推送是一种在客户端请求之前发送数据的机制。网页使用了许多资源：HTML、样式表、脚本、图片等等。在HTTP1.1中这些资源每一个都必须明确地请求。这是一个很慢的过程。浏览器从获取HTML开始，然后在它解析和评估页面的时候，增量地获取更多的资源。因为服务器必须等待浏览器做每一个请求，网络经常是空闲的和未充分使用的。
为了改善延迟，HTTP2.0引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前，免得客户端再次创建连接发送请求到服务器端获取。这样客户端可以直接从本地加载这些资源，不用再通过网络。
image
- 头部数据压缩
在HTTP1.1中，HTTP请求和响应都是由状态行、请求/响应头部、消息主体三部分组成。一般而言，消息主体都会经过gzip压缩，或者本身传输的就是压缩过后的二进制文件，但状态行和头部却没有经过任何压缩，直接以纯文本传输。
HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。
