彻底搞定网络协议
一、基础知识和环境搭建
互联网中的信息交流，并不是简单的我将信息提交到互联网，然后你就收到信息。而是要通过一系列的复杂的过程。
1.数据是如何从一个设备传递到另一个设备的？
这一切都是由网络协议来规定的。可以说，没有网络协议，就没有今天的互联网！
常见的网络协议：HTTP（HTTPS、SMTP、MQTT、RTPM等）针对不同的需求使用不同的协议
2.不同的领域常会问的网络协议面试题：
我们学习网络协议的意义：更多的去了解深网络协议层次的原理，从而更好的配合网络安全进行测试。
3.学习环境的搭建：
| C/S开发环境 |
|---|
| 服务器：java |
| 客服端：浏览器 |
抓包：浏览器、fiddler、wireshark
模拟工具：Xshell、packet tracer、GNS3
客服端和服务器的数据交互模型
java语言特性的说明（为什么环境要这样搭建)：
C/C++和java的对比
C/C++代码的跨平台方式：跨平台原理是针对不同的平台编译成不同的格式。
例如
-
要在mac上运行就要将代码编译成mach-o格式
-
要在windows上面运行就要编译为PE格式
-
要在linux上运行就要编译成ELF格式
针对不同平台就要进行多次编译，使用平台相关的编译器生成对应平台的可执行文件。
java代码的跨平台方式：java只需要编译一次，将代码编译为自解码文件，对于操作系统来说不是直接的可执行文件。
在不用的系统上安装JVM（java virtual machine），由jvm软件去加载.class文件，翻译为机器指令。如果代码有错误会编译失败，就不会生成字节码文件。
特性：一次编译到处运行。
安装JDK就能够使用JVM
搭建jdk环境
安装jdk-8u241-windows-x64
取消安装公共JRE
更改安装路径为想要的路径
完成安装
配置环境变量
右键此电脑点击属性，找到高级系统设置
添加jdk的bin目录即可
配置JAVA_HOME
添加bin和jre\bin目录
最后解压tomcat到对应目录完成环境搭建
扩展：如何搭建两个jdk环境，并且实现方便的切换java在一台电脑上装两个或多个jdk如何配置环境变量，并实现jdk切换 - 我不吃鸡儿 - 博客园
4.什么是端口号
端口号：相当于营业厅的办事窗口
各个端口去监听数据，运行不同的软件去处理不同的数据，这一类软件大致理解为服务器软件
当不同软件向服务器的同一个端口去发送数据的时候，这个时候就需要部署项目（部署不同的java项目）
在服务器端搭建环境，实现客服端和服务器端的通信
访问服务器软件
http://IP地址:端口号/项目
通过ip地址发现服务器、通过端口发现服务器软件、最后访问通过该端口通信的项目
访问本地搭建的tomcat
解压tomcat到指定目录，双击启动start.bat，访问http://127.0.0.1:8080
5.网络协议、互联模型
不同的网络协议内容，客服端和服务端的沟通是无法高效的，国际标准组织，制定标准比如统一的http协议使得通信变得更加便捷。
国际标准化组织ISO创建的OSI参考模型，具有七层结构
通过实践证明TCP/IP的4层协议才是实用的协议
请求过程
学习研究的过程中常把网络模型分为5层，下图展示了大致的请求过程，客户端将数据进行层层包装，然后通过介质如网线发送到服务器，服务器接收到数据包之后再经过层层的解包就得到发送的原始数据。服务器进行回包的时候亦是如此。
搭建JAVA服务器
-
创建一个空项目
-
设定项目位置
-
添加java模块
-
创建第一个模块 01_HelloWorld
-
创建一个java类，命名为 main.java
-
将代码链接web服务器的功能，需要添加web模块。
-
右键该项目，选择添加框架支持，选择web应 用程序，应用即可
服务器和客服端搭建到本地，访问的大致流程如下，客服端通过8080端口请求tomcat发送数据
-
将tomcat集成到idea中，添加本地tomcat服务器
-
在项目结构中添加tomcat依赖
java的类最好是要有包（层层文件夹包含），方便在不同的文件夹能够取相同的文件名。
-
创建一个处理登录请求的登录页面
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>登录</title>
</head>
<body>
<form action="/hello/login" method="post">
<div>用户名<input name="username"></div>
<div>密码<input name="password"></div>
<button type="submit">登录</button>
</form>
</body>
</html>
-
创建com.mj.servlet.LoginServlet处理登录请求
package com.mj.servlet;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
@WebServlet("/login")
public class LoginServlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest requst, HttpServletResponse response) throws ServletException, IOException {
doPost(requst,response);
}
@Override
protected void doPost(HttpServletRequest requst, HttpServletResponse response) throws ServletException, IOException {
//1.获取客服端请求发送的数据（请求参数）
String username = requst.getParameter("username");
String password = requst.getParameter("password");
System.out.println(username + "_" + password);
//2.判断
if("123".equals(username) && "456".equals(password)){
response.getWriter().write("Login Success");
}
else{
response.getWriter().write("Login Falure");
}
}
}
计算机之前的通信基础
基础的通信需要知道对方的ip地址和网卡地址（MAC地址）
-
源ip地址------目标ip地址
-
源mac地址-----目标mac地址
确认了目标mac地址是自己才会将数据传递到上一层进行处理
实现两台电脑的连接方式，直接用两根网线进行连接
-
packet tracer演示
配置两台电脑通过ping和仿真的方式看是否能相互通信
ping测试
仿真测试
发广播的目的是获取对方的mac地址
arp数据包，目标mac地址为全F代表广播
6.集线器、网桥、交换机
相同设备使用的交叉线，不同设备之间使用紫铜线
-
同轴电缆---半双工通信、容易冲突、不安全、中间一断全都瘫痪
-
集线器（相当于同轴电缆升级版）
半双工、容易冲突、不安全、不智能
集线器广播时，会将数据包发送给连接到集线器的所有设备（hub没有智商、很傻）
如果当集线器连接了1000多台设备发送数据包的时候，就会长时间占用带宽，设备越多，效率越低。
-
网桥
能够得知每个接口那侧的mac的地址，起到隔绝冲突域的作用。就意味着左右两侧可以同时进行通信。
当网桥收录了一侧的mac地址后，当收到数据包的时候发现发送的数据包在同侧，就直接会在网桥处进行切断，不会再往网桥的另外一边进行转发。
-
交换机
全双工通信、相当于接口更多的网桥、比集线器安全
交换机能够记录好ip地址，直接将数据包发送到指定的计算机上面去。
如果全球的计算机的都连接到交换机上，ip地址是远远不够的，交换机连接的电脑属于同一个网段。在最开始交换机没有记录mac地址的时候，会发arp广播去询问mac地址，当每个主机都发送arp广播的话，大量的计算机同时广播会极大的占用带宽。广播风暴（就出问题了）
-
路由器（router）
实现在不同网段中转发数据
隔绝广播域
主机发送数据之前，首先会判断目标主机的ip地址跟它是否在同一个网段
-
在同一个网段：通过交换机、集线器等发送arp广播
-
不在同一个网段：通过路由器进行网段的判断，从而将数据发送到目标网段的网关接口
网关的设置
配置好路由器两边的网关设置，网关需要和同一边的局域网处于同一网段。
配置完成后打开该端口
配置每台计算机的默认网关，在哪一侧就使用哪一侧端口的网关
实现计算机2和计算机5之间的通信
1.通过网线直连、同轴电缆、集线器、网桥、交换机连接的设备在同一网段、同一广播域
2.网桥和交换机可以起到隔绝冲突域
二、MAC地址、IP地址
1.MAC
每一个网卡都有一个6字节(48bit)的MAC地址（Media Access Control Address）
前3个字节OUI，组织唯一标识符，由IEEE的注册管理机构分配给厂商
后3个字节网络接口标识符，由厂商自行分配
不同厂商的oui标识查询： http://standards-oui.ieee.org/oui/oui.txt
不同设备MAC地址的表示方式
Windows 40-55-82-0A-8C-6D
Linux、Android、Mac、 IOS 40:55:82:0A:8C:6D
Packet Tracer 4055.820A.8C6D
-
当48位mac地址全为1时，代表广播地址 FF-FF-FF-FF-FF-FF
更改mac地址
可以尝试通过更改mac地址来欺骗交换机，达到能进校园网上网的功能
mac地址的获取
设备通过arp广播来获取到目标主机的mac地址
获取成功后会缓存IP地址、MAC地址的映射关系，俗称：ARP缓存
动态获取dynamic，保存期限为两分钟，两分钟后又要重新获取。
arp -a ip 查询arp缓存
arp -d ip 删除arp缓存
arp -d 所有保存的ip对应的mac
2.IP地址
windows查询ip地址 ipconfig /all
互联网上每一个主机都有一个IP地址
字节层面上：将ip地址分为4个部分换算成10进制为192.168.1.10
ip地址的组成
网络标识（网络id）、主机标识（主机id）
子网掩码&IP地址得出网段（逐位相与）
IP地址：192.168.1.10
子网掩码：255.255.255.0
前三个部分 192.168.1 代表网络id
最后一个部分 0 代表主机id
已知ip地址需要结合子网掩码来判断网段、网络id和主机id
主机位全0表示一个网段，主机位为255.255表示广播，给这个网段所有的主机发送广播
所以实际可用的地址为256*256-2
ip地址的分类
D类地址和E类地址不会使用到主机上
-
A类地址
子网掩码为255.0.0.0
网络id部分不能为全0，127作为保留网段，所以网络位取值为：1~126
127.0.0.1为环回地址（Loopback），代表本机地址。
-
B类地址
子网掩码为255.255.0.0
最小网络位为128.0最大网络位为191.255
每一个网络位可容纳主机数为256*256-2，减掉了广播地址和网段地址
-
c类地址
子网掩码为255.255.255.0
最小网络位为192.0.0最大网络位为192.255.255
每一个网络位可容纳主机数为256-2，减掉了广播地址和网段地址
-
D类地址、E类地址
子网掩码
CIDR表示方法
192.168.1.100/24，代表子网掩码有24个1，即子网掩码为255.255.255.0
掩码、网段、可用ip广播等在线计算 在线网络计算器 | TCP/IP子网掩码计算换算 —在线工具
3.子网划分
-
如果需要两百台主机在同一个网段内，可用分配一个C类网段，比如192.168.1.0/24
这样就有254个可用的ip地址为：192.168.1.1~192.168.1.254
多出了54个空闲的ip，不算浪费资源
-
将500台主机放在同一网段中，分配一个B网段，如191.100.0.0/16
共有65536-2个可用地址减去分配的500台剩下65034个ip没有使用造成了极大的资源浪费
等长、变长子网划分
合理进行子网划分避免浪费ip资源
等长子网划分
-
等分成2个子网
划分为2个子网段
A子网：192.168.0.0/25，子网掩码为255.255.255.128 能够容纳126个主机（00000000代表网段，01111111代表广播地址）192.168.0.1~192.168.0.126
B子网：192.168.0.128/25，子网掩码为255.255.255.128 能够容纳126台主机（10000000代表网段，11111111代表广播地址）192.168.0.129~192.168.0.254
-
划分为4个子网
-
划分为8个子网
A类子网和B类子网划分类似
变长子网划分
将子网地址块划分为原网段的1/2
不等长的子网，他们的子网掩码也不同
假设上图为192.168.0.0/24对上图进行子网划分得出的网段为：
思考各网段的网络号是多少？
子网划分实验
设置两台计算机，分配ip和子网掩码为子网划分后的网段
计算机0 ip为192.168.0.10，子网掩码为255.255.255.128
计算机1 ip为192.168.0.80，子网掩码为255.255.255.128
测试能够正常通信
设置计算机为192.128.0.129/25尝试是否能够通信，发现不能够进行通信，说明两台计算机不在同一个网段，
要使得两个网段能够通信需要在之间加一个路由器，首先进行广播获取mac地址，然后发送icmp报文成功实现通信。
子网划分器：子网划分工具--子网划分器
超网、静态路由
在计算两台计算机确认是否能够通信的时候是用的本机的子网掩码进行计算
超网
超网简介
超网就相当于跟子网反过来，将多个连续的网段合并成一个更大的网段。
比如针对一个C类地址将网络部分的一位划分到主机部分，主机位就变成了9个二进制位，得到的可用主机数量就翻倍。
将192.168.0.0/24和192.168.1.0/24合并为同一个网段为192.168.0.0/23
子网掩码向右边挪移位就是划分子网，规模变小，向左边挪就是扩展为超网，规模就变大。
思考192.168.0.255/23这个ip是否可以分配给计算机使用？
1、计算192.168.0.255/23这个ip地址的网段为192.168.0.0/23
2、去除主机号为全零的网段地址192.168.0.0/23
3、去除主机号为全1的广播地址192.168.1.255/23
所以可以被分配的ip为192.168.0.1/23~192.168.1.254
所以192.168.0.255/23这个ip地址可以被分配给计算机使用
子网合并及注意事项
将子网掩码向左移动两位，可以合并4个网段为1个网段。如以下的网段就合并为192.168.0.0/22
注意事项
要将两个网段进行合并，需要注意的是合并的网段必须是连续的，对于C端网络来说，当需要合并两个网段为一个网段的时候，只有当ip地址的第三部分的最后一位不相同，其他位相同的时候才能够进行合并。当需要合并4个网段为1个网段的时候需要ip地址第三部分的最后两位不同，其他位相同才能够进行合并。
合并网段的规律
子网掩码向左移动一位合并个2子网，向左移动两位合并4个子网，向左移动三位合并8个子网。
合并2个子网：
开头的网段的最后一位要能够被2整除
第一个网段的网络号以二进制0结尾，那么由它开始连续的2个网段就能够通过左移1位子网掩码进行合并
合并4个子网：
开头的网段的最后一位要能够被4整除
第一个网段的网络号以二进制00结尾，那么由它开始连续的4个网段就能够通过左移2位子网掩码进行合并
以此类推
第一个网段的网络号以二进制000结尾，那么由它开始连续的8个网段就能够通过左移3位子网掩码进行合并
判断一个网段是子网还是超网
根据默认的子网掩码判断网络位是否左移还是右移
例如：192.168.0.1/23就是一个C类超网
首先因为这个网段为C类地址，默认的子网掩码为24位，但是现在只有23位说明子网掩码向左移动了一位，主机位多了一个二进制数，此时为将子网合并为一个大的网络，所以此时是合并为了一个C类超网。
三、路由
练习1--实现4台主机之间相互通信
分析 4个区域的计算机和路由器的对应的网关网关处于同一网段
1.packet tracer路由配置实验
（使得所有机算计能够互相通信）
配置路由器和交换机为以下的参数
-
测试计算机0和计算机1是否能够通信
实现通信
-
测试计算机2和计算机3是否能够通信
实现通信
-
测试计算机0和计算机3是否能够通信
测试无法通信，路由器返回信息无法到达目的地址（路由器无法找到这个网段的位置）
默认情况下，路由器只知道跟它直连的网段，非直连的网段需要通过静态路由、动态路由告诉它
2.静态路由配置
配置静态路由使得路由器两边的网段能够进行通信
配置静态
配置网络和掩码为目标网段，配置下一跳为要传输数据的下一个路由器接口地址
配置serial2/0
配置ip和子网掩码确保两个路由器连接的接口为同一网段
参照路由器0的配置，路由器1的配置原理相同
-
查看路由器0的路由表
可以观察到在设备中的配置本质就是在执行命令行界面的这些命令
补充
-
配置特定的ip地址
在静态路由的配置中如果需要配置特定的ip地址，需要将掩码改为255.255.255.255
-
配置一个静态路由使得能够同时访问
配置静态路由网段为192.168.0.0使用计算机4访问计算机0成功实现访问
-
配置默认路由
不知道访问的地址是怎么走的设置网络和掩码为0.0.0.0，设置默认的下一跳，这样就设置为了默认路由。
优先配置连接路由器少的区域
练习
为了能够实现通过路由器访问的没有通过路由器直连并且没有在同一网段的计算机，配置所有路由和计算机使得所有的电脑能够相互通信。
根据图中所示配置了以下内容
1.各台计算机的ip地址、子网掩码和网关地址
2.路由器与计算机相连接的端口ip（FastEthernet0/0）、路由器之间相互连接的ip地址(Serial2/0)
3.配置的各台路由器中的静态路由
静态路由的配置如下，为了实现配置的方便、更能够方便的查找，直接使用了默认路由设置，使得各个计算机在想与目的计算机通信的时候能够自动的寻找目的ip
路由表参考答案
路由设置思路:配置静态路由的时候边缘路由器可以直接配置为默认路由，但是在中间的路由器左右都连接了设备的情况下，在设备少的一边可以配置固定ip，在设备多的一边就配置为默认路由，如下图所示，路由器0和3位边缘路由，路由器1和2为连接了两个设备的中间路由。
3.数据包的传输过程
上图所示，在数据包的传输过程中源ip和目标ip是不会变化的，但是源MAC和目标MAC是会随着数据包的传输而发生改变
4.网络
网络（Network）互联网（internet）因特网（Internet）
ISP（Internet Service Provider）
中国的internet服务提供商，移动，电信，网通，铁通等
家庭的宽带都是通过ISP连接到Internet的
-
为什么在一些网站中会存在不同isp的下载地址？
因为有不同的运营商提供的机房下载时通过自己网络类型进行选择会一定的提高下载的速度
网络分类
局域网（LAN）
一般是范围几百米到几十公里内的计算机所构成的计算机网络
常用于公司、家庭、学校、医院、机关、一栋大楼
局域网使用广泛的网络技术：以太网
在电脑和手机上的WLAN（Wireless LAN），无线局域网
城域网（MAN）
一般范围是数十公里到数百公里，可以覆盖一个城市
广域网（WAN）
一般范围是几百公里到几千公里，可以覆盖一个国家。通常需要租用ISP的线路
分布较为广泛的分公司可以租用ISP的线路进行网络的构建，实现公司之前的通信。
5.常见的的接口
FastEthernet 快速以太网接口(100M)
GigabitEthernet 千兆以太网接口(1000M)
Serial 串行接口（一般是在路由器上面）
6.上网方式
电话线入户
光纤入户
网线入户
家用无线路由器的逻辑结构
7.公网ip和私网ip
ip地址分为公网的ip和私网的ip
-
公网ip
Internet上的路由器中只有到达公网的路由器，没有到达私网的路由器表
公网IP由因特网信息中心（NIC）统一分配和管理
ISP需要向Inter NIC申请公网ip
-
私网ip
主要用于局域网。
保留的私网网段
internet上的设备是无法知道私网地址的
NAT（Network Address Translation）
客户端172.18.250.6和百度服务器202.108.22.5通信，172.18.250.6发送数据时，先转换为219.155.6.240:1723（任意>1024的随机端口），然后再利用这个身份发送数据给百度服务器，然后百度服务器回应数据并发送给219.155.6.240:1723，NAT网关检查自己的关联表，意识到这是自己地私网中172.18.250.6的数据包，然后把这个数据发送给客户端
将私网网段中的设备ip转换为公网的ip地址，使得不同私网中的相同ip虽然有冲突但是也能够相互通信
NAT的特点
可以节约公网IP资源，会隐藏内部真实的IP
NAT的分类
-
静态转换
手动配置NAT映射表，一对一转换
-
动态转换
定义外部地址池，动态随机转换吗，一对一转换
以上两种方式都无法起到节约ip地址的目的，因为私网ip地址还是单独对应了一个公网ip地址
-
PAT(Port Address Translation)
多对一转换，最大程度节约了ip资源
采用端口多路复用方式，通过端口号标识不同的数据流
例如：通过对不同的ip地址进行端口标识，最终汇聚到同一个ip地址
192.168.1.10:23123->200.0.0.10:23123
192.168.1.11:7676->200.0.0.10:7676
192.168.1.12:7676->200.0.0.10:64565
PAT是目前应用最广泛的NAT实现方式
四、网络互联模型
1.不同的路由器
-
为什么在第一个包的请求中数据会丢失？
当计算机4 ping 计算机5的时候第一个数据包发生了丢失
是因为在最开始需要找到目标ip的时候需要用到发送arp广播知道对方的广播，这之前，在发送第一个数据包的时候数据包到了路由器3，路由器3是发现这个ICMP包不是给自己的，自己也不知道这个包的接收者在哪儿，由于忙碌，就直接将icmp包丢了，然后路由器再转发arp包询问计算机6的mac地址最后知道地址后再进行icmp包的转发。
-
路由器是否可以连接同一个网段呢？
是可以的，区别在于不同的路由器，部分路由器型号是支持连接同一网段的网络的。
可以看到819HG-4G-IOX路由器的快速以太网口是不用设置IP地址和子网掩码的，相当于实现了交换机的功能，是可以连接同一网段的计算机的。
2.网络互联模型
OSI参考模型，具有7层结构，但是实际运用中更多用到的是4层的TCP/IP协议，但这里我们分为5层对相关知识进行讨论。
3.请求过程
在请求过程中，客户端的数据包首先通过应用层进入其他层，进行层层打包，然后传输到服务器再经过层层的解包才得到原始的数据，每一层添加的数据都是必要且有用的，缺少了任何一层的功能都无法完成数据的传输。
4.网络分层
物理层
比特流 Bits
物理层定义了接口标准、线缆标准、传输速率、传输方式等
数字信号和模拟信号
数据通信模型
信道
信息传输的通道，一条传输介质上（比如网线）可以有多条信道
信道上可以传输不同的信息
1.单工通信
信号只能够想一个方向传输，任何时候都不能够改变信号的方向
比如无线电广播和有线电视
2.半双工通信
信号可以双向传输，但是只能交替进行，同一时间只能想一个方向传输
比如对讲机
3.全双工通信
信号可以同时双向传输
比如手机
数据链路层
（帧Frames）
链路：从一个节点到相邻节点的一段物理线路（有线或者无线），中间没有其他交换节点，集线器是咩有智商的，集线器穿插到链路中间时候，两边的线路还是算同一条链路。相当于忽略掉中间的集线器。
封装成帧
以太网理解为CSMA/CD协议，MTU限制为1500个字节
每一个帧都有帧开始符和帧结束符，区别不同的帧的开始和结束。
透明传输
数据部分一旦出现了SOH、EOT，就需要进行转义
在传输的过程中加上ESC数据包，在接收的一旦发现有跟上ESC的时候就直接去掉ESC
差错检验
在信道的传输过程中数据可能会失真，通过差错检验可以大概率保证数据的正确。
FCS=（帧的数据部分+数据链路层首部）的校验
通过计算帧的数据部分和数据链路层首部得到FCS，通过核验FCS查验数据是否有错误
当检验数据时候发生错误，会将错误的数据丢弃。
在不同的链路的传输中会除去之前的首部和尾部加上另外链路特有的首部和尾部。
-
CSMA/CD协议
载波监听多路访问/冲突检测
冲突检测：判断收到的数据是被弹回的数据还是其他设备发送的数据。
一般集线器会使用到这个协议，称使用了CSMA/CD的网络可以称为以太网，传输的为以太网帧
以太网帧格式：Ethernet V2标准 IEEE802.3标准，最多使用Ethernet V2标准
为了检测正在发送的帧是否发生了冲突，以太网的帧至少需要64字节（理论上计算出来了为64字节，两倍的通道长度）
当发送的帧足够长的时候，当帧还在发送的时候发生了碰撞收到了自己发送的帧头的时候(同时检测到了头部和尾部)，就能够判定为发生了冲突，一般要求发送的帧为信道的两倍长，理论上就是64字节。
交换机虽然不需要使用CSMA/CD协议了，但是传输的帧依然是以太网帧，所以用交换就组建的网络依然可以叫做以太网。
-
Ethernet V2帧
使用了曼彻斯特编码就不需要使用帧开始符和帧结束符了
以太网帧：首部+数据+FCS
首部：源MAC+目标MAC+网络类型
类型：使用的是ipv4网络还是ipv6网络
数据：数据部分至少需要46字节
标准
👻当数据部分的长度小于46字节时 数据链路层会在数据的后面加入一些字节填充，接收端会将添加的字节去掉
👻长度总结 以太网帧的数据长度: 46~ 1500字节 以太网帧的长度: 64~1518字节(目标MAC +源MAC+网络类型+数据+ FCS)
-
PPP协议(Point to Point Protocol)
PPP协议的字节填充
点到点链路是不需要源mac和目标mac一定是从一端到另外一端的，所以A部分为FF
在传输到路由器的时候帧是不一样的，首部和尾部发生了变化，但是网络层的东西是一样的
源IP和目标IP是不变的，到其他设备时源mac和目标mac会发生变化，首部和尾部会发生变化
当两个路由器之间接了交换机的时候发送的帧就不是PPP协议帧了而是以太网帧，就包含了源mac地址和目标mac地址
思考PPP协议帧为什么不需要源mac地址和目标mac地址？
点对点协议就是从路由器的一头传到另一个路由器，当两个路由器相连的时候也不需要发送广播，直接就可以进行数据的传输，所以不需要源mac地址和目标mac地址。
-
网卡
使用wireshark抓取数据包进行分析，接收到的数据包只有14个字节，为什么没有FCS？
网卡接收到一个帧，首先会进行差错校验，如果校验通过则接收（会直接丢掉帧尾的FSC），校验失败就直接丢弃数据包的所有内容。
集线器，交换机，路由器分别属于那些网络分层？
集线器属于物理层，交换机属于数据链路层，路由器属于网络层。
网络层
（packets）
网络层数据包由两个部分构成(IP数据包，Packet）由首部和数据两部分组成
数据很多时候是由传输层传输下来的数据段
数据包解析
首部
■版本(Version) 占4位 0b0100: IPv4 0b0110: IPv6 ■首部长度(Header Length) 占4位,二进制乘以4才是最终长度 0b0101: 20 (最小值) 0b1111: 60 (最大值)
首部长度一般都为20bit
■区分服务(Differentiated Services Field) 占8位 可以用于提高网络的服务质量(QoS, Quality of Service)，让优先级高的先通信
区分服务字段一般为全零，没有设置
■总长度
占16位，首部+数据长度之和，最大值为65535
■由于帧的数据不能超过1500字节，所以过大的IP数据包，需要分成片(fragments) 传输给数据链路层 每一片都有自己的网络层首部 (IP首部)
帧分割后是怎么重新合并到一起的还原为一个完整的ip数据包？
每一片数据都会有IP首部，可以通过IP首部重新合并到一起
■标识(Identification) 占16位 数据包的ID，当数据包过大进行分片时，同一个数据包的所有片的标识都是一样的 有一个计数器专门管理数据包的ID,每发出一个数据包， ID就加1
当ping百度的时候wireshark中可以查看被分割的数据包，发送一个用于ping的ICMP数据包被分割为了三个部分，前两个包为ip数据包，查验到最后一个包的时候识别出了为ICMP数据包。
■标志(Flags) 占3位 第1位(Reserved Bit) :保留 第2位(Don't Fragment) : 1代表不允许分片，0代表允许分片 第3位(More Fragments) : 1代表不是最后一片, 0代表是最后一片
cmd中ping ke.qq.com
设置数据包大小为4000并且不允许分片，可以发现包发送不出去
■片偏移（Fragment Offset）
占13位，片偏移乘以8才表示字节偏移
使用指定数据包进行ping的时候有ICMP的8个字节的头部加上数据包头部的固定20字节再加上发送的800个字节总共就是828个字节
ICMP头部的8个字节
-
ping 的几个用法
ping /? //查看ping的用法 ping ip地址 -l 数据包大小 //发送指定大小的数据包 ping ip地址 -f //不允许网络层分片
■协议
表明网络层包装的协议是什么
部分的数据没有走所有的网络分层，有些数据会通过传输层传输到网络层，但是有些数据只是属于网络层就没有用到传输层的协议。部分协议只工作在网络层 ，比如ARP IP ICMP。
packet tracer验证
通过数据包可见ICMP属于网络层的协议，逐层往下传输数据。
arp协议是链接数据链路层和网络层的协议，ICMP是链接运输层和网络层的协议
各种协议的10进制标志
■首部检验和
将首部进行计算，检验出一个值确保数据的正常
■生存时间（Time To Live, TTL）
占8位，每个路由器在转发之前都会将TTL减1，一旦发现TTL减为0，路由器就会返回错误报告
观察使用Ping命令后的TTL可以推测出对方的操作系统，中间经历了多少个路由器
通过tracert 、pathping命令，可以跟踪数据包经过了哪些路由器
意义：
路由器有路由表，当两个路由器都是对方的默认路由，此时如果没有生存时间，这个数据包就会无限的在两个路由器之间进行转发，无限占用带宽，造成了死循环。
不同的操作系统会有不同的TTL值
ping ip地址 -i TTL //设置TTL的值 //通过tracert、pathping命令 ，可以跟踪数据包经过了哪些路由器
传输层
Transpor
TCP(Transmission Control Protocol)，传输控制协议
UDP(User Datagram Protocol)，用户数据报协议
TCP发送会有失败重传的机制，所以用于浏览器、文件传输等，实时通信的话一般使用UDP协议，确保在直播或者通话的时候没有过重传。
应用层使用HTTP、HTTPS、FTP、SMTP、DNS协议的数据通常会传入网络层接着使用TCP协议传输数据。
UDP
UDP是无连接的，减少了建立和释放连接的开销 UDP尽最大能力交付，不保证可靠交付 因此不需要维护一些复杂的参数，首部只有8个字节(TCP的首部至少20个字节)
UDP长度(Length) 占16位，首部的长度+数据的长度
-
检验和
伪首部+首部+数据
伪首部尽在计算检验的时候起作用，不会传递给网络层，使检验更加严谨，更加安全，检错能力更强
-
端口号
常见的协议使用的默认端口号
UDP首部中端口是占用2字节 可以推测出端口号的取值范围是: 0~ 65535
客户端的源端口是临时开启的随机端口 服务器的端口一般为固定端口，设置给其他的客服端提供服务
防火墙可以设置开启\关闭某些端口来提高安全性 服务的访问不是说你开启了3306端口就能直接访问mysql数据库，一般是通过HTTP协议间接性的通过内部访问数据库中的数据。通过防火墙关闭外界对一些端口的访问可以阻止一些非法的请求。
常用命令行
netstat -an //查看被占用的端口 netstat -anb //查看被占用的端口、占用端口的应用程序 telnet主机端口 //查看是否可以访问主机的某个端口 安装telnet: 控制面板-程序-启用或关闭Windows功能-勾选"Telnet Client” -确定
通过telnet命令连接端口，可以连接正在使用这个端口的服务，比如连接到使用3306端口的mysql就会要求输入mysql的账号密码进行登录
5.TCP
UDP数据包对比示例
TCP数据格式
-
数据偏移
判断首部长度 占4位，取值范围是0x0101~0x1111 乘以4:首部长度(Header Length) 首部长度是20~60字节
-
保留
占6位，目前全为0
-
检验和
跟UDP一样，TCP检验和的计算内容:伪首部+首部+数据 伪首部:占用12字节，仅在计算检验和时起作用，并不会传递给网络层
-
标志位
URG(Urgent) 当URG=1时，紧急指针字段才有效。表明当前报文段中有紧急数据，应优先尽快传送
ACK (Acknowledgment) 当ACK=1时，确认号字段才有效
PSH（Push）
RST (Reset) 当RST=1时，表明连接中出现严重差错,必须释放连接,然后再重新建立连接
SYN (Synchronization) 当SYN=1、ACK=0时,表明这是一个建立连接的请求 若对方同意建立连接，则回复SYN=1、ACK= 1
FIN(Finish) 当FIN= 1时，表明数据已经发送完毕，要求释放连接
-
序号(Sequence Number)
占4字节 首先，在传输过程的每一一个字节都会有一个编号 在建立连接后，序号代表:这一次传给对方的TCP数据部分的第一个字节的编号
-
确认号(Acknowledgment Number)
占4字节 在建立连接后，确认号代表:期望对方下一-次传过来的TCP数据部分的第一个字节的编号
-
窗口(Window)
占2字节 这个字段有流量控制功能，用以告知对方下一 次允许发送的数据大小(字节为单位)
TCP的细节
1.有些资料中，TCP首部的保留(Reserved) 字段占3位，标志(Flags) 字段占9位，Wireshark中也是如此
都可以认为是正确的，因为在保留的9位中前三位是没有使用的，所以算入了保留位也是可以的。
2.UDP的首部中有个16位的字段记录了整个UDP报文段的长度(首部+数据) 但是，TCP的首部中仅仅有个4位的字段记录了TCP报文段的首部长度，并没有字段记录TCP报文段的数据长度。
分析
UDP首部中占16位的长度字段是冗余的，纯粹是为了保证首部是32bit对挤 TCP\UDP的数据长度，完全可以由IP数据包的首部推测出来 传输层的数据长度=网络层的总长度-网络层的首部长度-传输层的首部长度
可靠传输
将完整的数据切成几块发出去后，发现有丢失的包，能够将这个包进行重新发送。
-
停止等待ARQ协议
发现效率很低，提出改进方案
-
连续ARQ协议+滑动窗口协议
窗口大小由接收放确认
对滑动窗口协议的详细分析
在发送过程中如果遇到了数据丢失，这时候如果使用了SACK选择性确认，就只是重新发送丢掉的那个数据包，不会发送已经发送的数据包。
发送数据的时候窗口是可变的，给回数据的时候会给发送方确认窗口大小。
-
SACK（选择性确认）
在TCP通信过程中，如果发送序列中间某个数据包丢失(比如1、 2、3、4、5中的3丢失了) TCP会通过重传最后确认的分组后续的分组(最后确认的是2，会重传3、4、5) 这样原先已经正确传输的分组也可能重复发送(比如4、5)，降低了TCP性能
为改善.上述情况，发展出了SACK (Selective Acknowledgment），选择性确认技术 告诉发送方哪些数据丢失,哪些数据已经提前收到 使TCP只重新发送丢失的包(比如3)，不用发送后续所有的分组(比如4、5)
SACK实现原理 在长度可变的选项中放入SACK，表示哪些字节没有收到哪些字节收到了。
SACK信息会放在TCP首部的选项部分
Kind:占1字节。当值为5的时候，代表这是SACK选项 Length:占1字节。表明SACK选项一共占用多少字节 Left Edge:占4字节，左边界. Right Edge:占4字节，右边界
一对边界信息需要占用8字节，由于TCP首部的选项部分最多40字节，所以 40减去Kind和Length占用，40-2=38字节可以用来作为边界信息，所以SACK选项最多携带4组边界信息 SACK选项的最大占用字节数= 4*8 + 2= 34
具体数据包展示
可以观察到一个问题，他的序号为1，但是原生序号为2790487164
用原生序号减去序号得到的编号可以当做数据包唯一标识，意味数据包为同一请求的数据，真正储存的序号是一个很大的值，显示中的1开始的值是通过计算得到的逻辑上的开始值 确认号也是这种方式进行换算。
思考：
为什么选择在传输层将数据进行分割，而不是等到网络层再分片传递给数据链路层？
因为可以提高重传的性能 需要明确的是:可靠传输是在传输层进行控制的 如果在传输层不分段，一旦出现数据丢失，整个传输层的数据都得重传 如果在传输层分了段，一旦出现数据丢失，只需要重传丢失的那些段即可
若有个包重传了N次还是失败，会一直持续重传到成功为止么?
这个取决于系统的设置，比如有些系统，重传5次还未成功就会发送reset报文(RST) 断开TCP连接
UDP的数据格式就更简单了，在他的传输机制中就没有重传机制无法保证可靠传输，头脑简单UDP
流量控制
发数据给流量的过程中，告诉了我接受窗口的大小，告诉窗口大小告诉服务器缓慢有序的发送数据过来。
接收窗口大小和缓存有关
如果接收方的缓存区满了，发送方还在疯狂的发送数据那么会产生什么影响？
接收方只能把收到的数据包丢掉，大量的丟包会极大着浪费网络资源 所以要进行流量控制
什么是流量控制？
让发送方的发送速率不要太快，让接收方来得及接收处理
原理 通过确认报文中窗口字段来控制发送方的发送速率 发送方的发送窗口大小不能超过接收方给出窗口大小 当发送方收到接收窗口的大小为0时，发送方就会停止发送数据
特殊情况
开始，接收方给发送方发送了0窗口的报文段 后面，接收方又有了一些存储空间，给发送方发送的非0窗口的报文段丢失了 发送方的发送窗口一直为零，双方陷入僵局
解决方案 当发送方收到0窗口通知时，这时发送方停止发送报文 并且同时开启一个定时器，隔一段时间就发个测试报文去询问接收方最新的窗口大小 如果接收的窗口大小还是为0,则发送方再次刷新启动定时器
拥塞控制
防止过多的数据注入到网络中 避免网络中的路由器或链路过载
理论上当R1路由器发送300M/s的数据R2发送500M/s的数据时，800M的数据可以绰绰有余的通过1000M的带宽，但是当R1路由器发送700M/s的数据R2发送600M/s的数据时，1300M的数据通过1000M的带宽时就会造成过载，就会丢弃过载的数据包。
随着输入的量越来越大，理想情况就是一直停留在1000M/s，实际上的吞吐量少于理想情况，再当输入的负载更多的增加时候，就会产生拥塞，到最后甚至会出现死锁的状态。
拥塞控制是一个全局性的过程 涉及到所有的主机、路由器 以及与降低网络传输性能有关的所有因素 是大家共同努力的结果
相对比而言，流量控制是点对点通信的控制
拥塞控制的方法
几个缩写
MSS（Maximum Segment Size）：每个段最大的数据部分大小，只会在建立连接时确定
| 传输层头部和数据包 | 20|1460 | 段，segment |
|---|---|---|
| 网络层头部和数据包 | 20|1480 | 包，packet |
| 数据链路层数据包 | 1500 | 帧，frame |
传输层头部为32个字节的时候是什么情况？
可以看到选项中存在MSS，和SACK，有些包中MSS是不一样的
当客服端和服务器中两个MSS数据支持的最大值不一样的时候取最小的那一个，这个过程叫做协商
cwnd(congestion window)：拥塞窗口
rwnd (receive window) ：接收窗口
swnd (send window) ：发送窗口
当网络通畅，拥塞窗口说现在发5000都没得问题，但是接收窗口能接收到数据为3000字节，所以只能发3000字节的数据。
当网络拥塞，接收窗口能接受3000的数据，但是拥塞窗口说现在有点堵请发送800字节的数据，最后就会发送800字节的数据
swnd = min(cwnd, rwnd) 发送窗口的发送的数据量取拥塞窗口和接收窗口中最小的一个
发送窗口的最大值: swnd = min(cwnd, rwnd) 当rwnd < cwnd时，是接收方的接收能力限制发送窗口的最大值 当cwnd < rwnd时，则是网络的拥塞限制发送窗口的最大值
慢开始
（slow start，慢启动）
相当于试探性的发送，最开始发送一个数据段，发现接收比较快，然后发送两个，接收也比较快，然后发送4个，发现网路依然通畅，最后依次增加发送的量。
总结：cwnd的初始值比较小，然后随着数据包被接收方确认(收到一个ACK)，cwnd就成倍增长(指数级)
拥塞避免
（congestion avoidance）
ssthresh (slow start threshold) :慢开始阈值，cwnd达到阈值后，以线性方式增加 拥塞避免(加法增大) :拥塞窗口缓慢增大,以防止网络过早出现拥塞 乘法减小:只要网络出现拥塞，把ssthresh减半，于此同时，执行慢开始算法(cwnd又恢复到初始值) 当网络出现频繁拥塞时，ssthresh值就下降的很快
快速重传、恢复
（fast recovery、retransmit）
接收方 每收到一个失序的分组后就立即发出重复确认，使发送方及时知道有分组没有到达，而不要等待自己发送数据时才进行确认。
发送方
只要连续收到三个重复确认相当于确认丢包了(总共4个相同的确认)，就应当立即重传对方尚未收到的报文段，而不必继续等待重传计时器到期后再重传
当发送方连续收到三个重复确认，就执行“乘法减小”算法，把ssthresh减半，是为了预防网络拥塞
与慢开始不同之处是现在不执行慢开始算法，即cwnd现在不恢复到初始值，而是把cwnd值设置为ssthresh减半后的数值，然后开始执行拥塞避免算法(“加法增大" )，使拥塞窗C缓慢地线性增大
抓包中的重传和快重传
6.连接管理
建立连接
wireshark抓包演示
三次握手建立连接
A发送SYN=1，ACK=0给B请求建立连接，B回复SYN=1，ACK=1给A表示同意建立连接，然后A发送给B，SYN=0，ACK=1表示成功建立连接
然后就可以发送http请求给服务器，服务器则对应返回很多的数据包
序号、确认号的详细解释
相对序号和原生序号：TCP报文中的1代表的是相对的序号，因为简单的序号会带来风险，容易被抓包导致所有数据的泄露，所以实际上的序号不能设置为1开始，那么怎么设置序号呢？
序号是在建立连接的时候确定的是随机的，在数据段中的序号和ACK号都是通过相应的计算得到的序号，实际的ACK序号和其他数据段的序号可以通过实际的序号进行计算得到。
图像分析：客户端和服务器建立通信的时候都会给对方确认一个随机的真实序号，实际发送的序号为初始序号+1，然后通过计算数据段的长度，确认返回的ACK值为初始序号+1+数据段的长度。
在建立连接的1,2,3步里面的序号和ACK详情，都是只有头部没有数据部分。
建立连接之后要开始发送http请求了
在3和4步ACK相当于对上一个请求的回应，在http请求中依然是A对B请求数据，并且没有接收到B的响应，所以发送的序号和ACK和上一个数据段一样
然后第四步发送了一个K字节的http请求，服务器应答，开始回复数据，每一个包的序号就是原生的序号加上之前所有包的字节大小再加1，每一个包的ack就是需要对方响应包的开始的字节序号
最后客服端给服务器一个应答，他发送的数据包序号为s1+k+1，希望服务器返回s2+b1+b2+b3+b4+1开始的数据包。
在确认包中TCP数据部分依然为0
客户端发送的序号初始值用在了客户端的序号和服务端的ACK号，服务器端的序号初始值用在了服务器的序号和客户端的ACK号。
三次握手
CLOSED: client处于关闭状态
LISTEN: server处于监听状态， 等待client连接
SYN-RCVD:表示server接受到了SYN报文，当收到client的ACK报文后，它会进入到ESTABLISHED状态
SYN-SENT:表示client已发送SYN报文，等待server的第2次握手
ESTABLISHED:表示连接已经建立
-
前两次握手的特点
在进行tcp连接的时候头部为32字节，其中12个字节包含的是选项中的数据
其中使用的有MSS、是否支持SACK、Window scale（窗口缩放系数）确认真正的窗口大小
为什么建立连接的时候，要进行3次握手? 2次不行么? 主要目的:防止server端一直等待， 浪费资源
如果建立连接只需要2次握手，可能会出现的情况
-
假设client发出的第一个连接请求报文段，因为网络延迟，在连接释放以后的某个时间才到达server
-
本来这是一个早已失效的连接请求，但server收到此失效的请求后，误认为是client再次发出的一个新的连接请求
-
于是server就向client发出确认报文段，同意建立连接
-
如果不采用"3次握手”，那么只要server发出确认,新的连接就建立了
-
由于现在client并没有真正想连接服务器的意愿，因此不会理睬server的确认， 也不会向server发送数据
-
但server却以为新的连接已经建立，并一直等待client发来数据，这样server的很多资源就白白浪费掉了
采用“三次握手”的办法可以防止.上述现象发生 例如上述情况，client没有向server的确认发出确认，server由于收不到确认,就知道client并没有要求建立连接
第3次握手失败了，会怎么处理？
此时server的状态为SYN-RCVD，若等不到client的ACK，server会重新发送SYN+ACK包 如果server多次重发SYN+ACK都等不到client的ACK，就会发送RST包，强制关闭连接
如果第三次握手没有成功，没有收到第三次握手的包，就会发送RTS报文段进入closed状态。
释放连接
4次挥手
FIN-WAIT-1:表示想主动关闭连接 向对方发送了FIN报文，此时进入到FIN-WAIT-1状态
CLOSE-WAIT:表示在等待关闭 当对方发送FIN给自己，自己会回应一个ACK报文给对方，此时则进入到CLOSE-WAIT状态 在此状态下，需要考虑自己是否还有数据要发送给对方，如果没有，发送FIN报文给对方
FIN-WAIT-2：只要对方发送ACK确认后，主动方就会处于FIN-WAIT-2状态，然后等待对方发送FIN报文
CLOSING：一种比较罕见的例外状态
表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文
如果双方几乎在同时准备关闭连接的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态 ，表示双方都正在关闭连接
LAST-ACK：被动关闭一方在发送FIN报文后，最后等待对方的ACK报文 当收到ACK报文后，即可进入CLOSED状态了
TIME-WAIT：表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可进入CLOSED状态了 如果FIN-WAIT-1状态下，收到了对方同时带FIN标志和ACK标志的报文时 ✓ 可以直接进入到TIME-WAIT状态，而无须经过FIN-WAIT-2状态
CLOSED：关闭状态 ◼ 由于有些状态的时间比较短暂，所以很难用netstat命令看到，比如SYN-RCVD、FIN-WAIT-1等
TIME-WAIT阶段的作用
TIME-WAIT一般为2MSL（（Maximum Segment Lifetime 最大分段生存期）
假如没有TIME-WAIT阶段，而是直接第三次挥手客服端后就进入了断开状态，这时候如果发送给服务端的最后一次挥手服务器迟迟收不到话，就会再发送第三次挥手的数据给客服端，但是此时客服端已经断开了连接，你发给他他也收不到呀，服务器那边就会干等，甚至多次重发FIN，浪费资源
第二种情况
客服端有个新的应用程序刚好分配了同一个端口号，新的应用程序收到FIN后马上开始执行断开连接的操作，本来它可能是想跟server建立连接的，但是这一个操作直接使得传输通道关闭了。
所以综上所述，TIME-WAIT在第四次挥手数据包丢失的情况下，让服务器端有时间重新发送第三次挥手的数据包。
为什么释放连接的时候，要进行4次挥手？
TCP是全双工模式
第1次挥手:当主机1发出FIN报文段时 表示主机1告诉主机2,主机1已经没有数据要发送了,但是，此时主机1还是可以接受来自主机2的数据
第2次挥手:当主机2返回ACK报文段时 表示主机2已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的
第3次挥手:当主机2也发送了FIN报文段时 表示主机2告诉主机1,主机2已经没有数据要发送了
第4次挥手:当主机1返回ACK报文段时 表示主机1已经知道主机2没有数据发送了。随后正式断开整个TCP连接
java程序演示
使用java程序来演示三次握手四次挥手原理
抓包
保活，心跳包问题
当服务器设有定时没有收到数据包就主动断开连接的机制的时候，此时让客服端每隔几秒就发送一个数据包给服务器，每次发送的数据包就相当于给服务器表明我还在连接中，这钟包就就称为心跳包。可以在应用层设置保活。TCP中存在keep-alive机制，可以设置心跳包，但是一般我们针对具体的情况自己进行编程或者构建策略来实现。
抓包时出现的三次挥手情况
是因为第二次和第三次的挥手被合并了
当server接收到client的FIN时，如果server后面也没有数据要发送给client了。这时，server就可以将第2、3次挥手合并，同时告诉client两件事
-
已经知道client没有数据要发
-
server已经没有数据要发了
区分长连接和短连接，一般看连接的目的，如果只是需要一个数据连接后马上就断开就算是短连接，但是如果需要长期保持连接就算是长链接。
短连接：创建好通道，做完一轮交互后马上就断开连接了
长连接：在Socket1中一启动就开始建立连接，点击发送的时候只是发送数据没有关闭通道而是保持连接，一般在我和你的交互很频繁的时候使用长连接。
在建立连接之后保持连接不断开对网卡会有影响吗？
不会，但是保留的socket对象会保留在内存里面，会一直占用内存。
客服端socket和服务器的ServerSocket连接
当客服端的Socket要和服务器端的ServerSocket断开连接只是会断开服务器中产生的和客服端对应的Socket对应程序，并不会关闭服务器的ServerSocket也不会对其他的Socket造成影响。每个客服端和服务器的连接时独立的。
7.应用层
常见的协议
超文本传输：HTTP、HTTPS 文件传输：FTP 电子邮件：SMTP、POP3、IMAP 动态主机配置：DHCP 域名系统：DNS
域名（Domain Name）
由于IP地址不方便记忆，并且不能表达组织的名称和性质，人们设计出了域名（比如baidu.com）
但实际上，为了能够访问到具体的主机，最终还是得知道目标主机的IP地址
域名申请注册：域名注册-工商财税-知识产权-资质备案-智能设计-网站建设-万网-阿里云旗下品牌
为啥不直接使用域名不用ip地址？
ip地址只占用4个字节，域名需要10多个字节，会增加路由器的负担，浪费流量。
根据级别不同，域名可以分为
顶级域名 二级域名 三级域名
通过顶级域名
通用顶级域名（General Top-level Domain，简称gTLD）
.com（公司），.net（网络机构），.org（组织机构），.edu（教育）
.gov（政府部门），.int（国际组织）等 ◼ 国家及地区顶级域名（Country Code Top-level Domain，简称ccTLD）
.cn（中国）、.jp（日本）、.uk（英国） ◼ 新通用顶级域名（New Generic Top-level Domain，简称：New gTLD）
.vip、.xyz、.top、.club、.shop等
二级域名
顶级域名之下的域名
在通用顶级域名下，它一般指域名注册人的名称，例如google、baidu、microsoft等 在国家及地区顶级域名下，它一般指注册类别的，例如com、edu、gov、net等
所有的DNS服务器都记录了DNS根域名服务器的IP地址
DNS（Domain Name System）
DNS的全称是：Domain Name System，译为：域名系统 利用DNS协议，可以将域名（比如baidu.com）解析成对应的IP地址（比如220.181.38.148） DNS可以基于UDP协议，也可以基于TCP协议，服务器占用53端口
每台DNS服务器知道的数据是有限的，不可能一台服务器把全世界的网址都记下来的，一般是分开管理
DNS一般使用UDP协议
客户端首先会访问最近的一台DNS服务器（也就是客户端自己配置的DNS服务器） ◼ 所有的DNS服务器都记录了DNS根域名服务器的IP地址 ◼ 上级DNS服务器记录了下一级DNS服务器的IP地址 ◼ 全球一共13台IPv4的DNS根域名服务器、25台IPv6的DNS根域名服务器
DNS的操作命令
ipconfig /displaydns：查看DNS缓存记录 ipconfig /flushdns：清空DNS缓存记录 ping 域名 nslookup 域名
DNS服务器
-
客户端首先会访问最近的一台DNS服务器(也就是客户端自己配置的DNS服务器)
-
所有的DNS服务器都记录了DNS根域名服务器的IP地址
-
DNS服务器是分层管理的，上一层DNS服务器记录了下一级的DNS服务器的IP地址
-
全球一共13台IPv4的DNS根域名服务器、 25台IPv6的DNS根域名服务器
IP地址的分配
静态ip和动态ip
静态ip
手动设置，适用的场景：不怎么挪用的台式机（比如学校机房中的台式机）、服务器
动态ip
从DHCP服务器自动获取IP地址 使用场景：移动设备、无线设备
DHCP (Dynamic Host Configuration Protocol)，译为:动态主机配置协议
DHCP协议基于UDP协议，客户端是68端口，服务器是67端口 DHCP服务器会从IP地址池中，挑选一个IP地址 “ 出租“给客户端- -段时间，时间到期就回收它们 平时家里上网的路由器就可以充当DHCP服务器
分配IP地址的4个阶段
-
DISCOVER:发现服务器 发广播包(源IP是0.0.0.0，目标IP是255.255.255.255， 目标MAC是FF:FF:FF:FF:FF:FF)
-
OFFER:提供租约 服务器返回可以租用的IP地址，以及租用期限、子网掩码、网关、DNS等信息 注意:这里可能会有多个服务器提供租约
-
REQUEST:选择IP地址 客户端选择一 个OFFER, 发送广播包进行回应
-
ACKNOWLEDGE: 确认 被选中的服务器发送ACK数据包给客户端 至此，IP地址分配完毕
具体的交互的4个数据包详情
DHCP服务器可以跨网段分配IP地址么? (DHCP服务器、 客户端不在同一一个网段) 可以借助DHCP中继代理(DHCP Relay Agent)实现跨网段分配P地址
自动续约 客户端会在租期不足的时候，自动向DHCP服务器发送REQUEST信息申请续约
常用命令 ipconfig /all: 可以看到DHCP相关的详细信息，比如租约过期时间、DHCP服务器地址等 ipconfig /release: 释放租约 ipconfig /renew: 重新申请IP地址、 申请续约(延长租期)
ipconfig /renew 出现的数据
要想重新实现具体交互的4个数据包可以先释放租约，在重新申请IP地址、申请续约
五、HTTP协议
1.简介
HTTP (Hyper Text Transfer Protocol)， 译为超文本传输协议
是互联网中应用最广泛的应用层协议之一 设计HTTP最初的目的是:提供一种发布和接收HTML页面的方法，由URI来标识具体的资源（URI包括URL） 后面用HTTP来传递的数据格式不仅仅是HTML，应用非常广泛
HTML ( Hyper Text Markup Language) :超文本标记语言 用以编写网页
超文本 用文本表达超出文本的东西，比如链接、图片等
维基百科
HTTP版本演变
1991年，HTTP/0.9 只支持GET请求方法获取文本数据(比如HTML文档)，且不支持请求头、响应头等,无法向服务器传递太多信息
1996年，HTTP/1.0 支持POST、HEAD等请求方法，支持请求头、响应头等，支持更多种数据类型(不再局限于文本数据) 浏览器的每次请求都需要与服务器建立一个TCP连接，请求处理完成后立即断开TCP连接
1997年，HTTP/1.1 (最经典、使用最广泛的版本) 支持PUT、DELETE等请求方法 采用持久连接(Connection: keep-alive) ，多个请求可以共用同一个TCP连接
2015年，HTTP/2.0 2018年，HTTP/3.0
标准
由万维网协会(W3C)、互联网工程任务组(IETF) 协调制定，最终发布了一系列的RFC
RFC (Request For Comments,可以译为:请求意见稿) HTTP/1.1最早是在1997年的RFC 2068中记录的 该规范在1999年的RFC 2616中已作废 2014年又由RFC 7230系列的RFC取代 HTTP/2标准于2015年5月以RFC 7540正式发表，取代HTTP/1.1成为HTTP的实现标准
中国的RFC 1996年3月，清华大学提交的适应不同国家和地区中文编码的汉字统一传输标准被IETF通过为RFC 1922 成为中国大陆第一 个被认可为RFC文件的提交协议
RFC请求意见稿查询https://tools.ietf.org/htm/
报文格式
查看本地回环地址的报文数据
可以查看到wireshark解析好的数据
发送给服务器的请求
追踪http流
浏览器会将数据分为http头和响应数据
HTTP头的格式规定是非常严格的，少一个空格多一个空格或者回车都是不行的。
POST请求报文会有请求体
响应报文的格式
由于GET请求在请求头，GET请求不能传太多的数据
-
对报文的详细深入解析
ABNF（Augmented BNF） 是BNF（Backus-Naur Form，译为：巴科斯-瑙尔范式）的修改、增强版 在RFC 5234中表明：ABNF用作internet中通信协议的定义语言 ABNF是最严谨的HTTP报文格式描述形式，脱离ABNF谈论HTTP报文格式，往往都是片面、不严谨的
关于HTTP报文格式的定义
RFC 2616 4.HTTP Message（旧） RFC 7230 3.Message Format（新）
整体的报文格式
start-line = request-line / status-line
start-line包含request-line和status-line他们内部会有一个换行CRLF
header-filed
消息体，0个或多个字节
URL编码
URL中一旦出现了一些特殊字符（比如中文、空格），需要进行编码 在浏览器地址栏输入URL时，是采用UTF-8进行编码
为什么是UTF-8编码？可以进行在线验证
或者通过java程序进行验证
Xshell和telnet
可以直接面向HTTP报文与服务器交互 可以更清晰、直观地看到请求报文、响应报文的内容 可以检验请求报文格式的正确与否
使用Xshell连接服务器直接发送报文，可以看到直接能够发送报文内容，也可以直接返回响应的数据
GET /hello/ HTTP/1.1 Host: localhost:8080
测试发现出现不止一个空格也能成功返回数据这是为什么呢？
因为不同的HTTP服务器有不同的容错能力，比如Tomcat在接收报文的时候能解析含有多个空格的请求体
2.请求方法
RFC 7231, section 4: Request methods:描述了8种请求方法 GET、HEAD、POST、 PUT、DELETE、 CONNECT、OPTIONS、TRACE
RFC 5789, section 2: Patch method:描述了PATCH方法
-
GET
常用于读取的操作，请求参数直接拼接在URL的后面(浏览器对URL是有长度限制的)
所以GET请求没办法传递大量数据，GET请求一般用于查询
-
POST
常用于添加、修改、删除的操作，请求参数可以放到请求体中(没有大小限制)
-
HEAD
请求得到与GET请求相同的响应，但没有响应体
使用场景举例:在下载一 个大文件前，先获取其大小，再决定是否要下载。以此可以节约带宽资源
-
OPTIONS
用于获取目的资源所支持的通信选项，比如服务器支持的请求方法
-
PUT
用于对已存在的资源进行整体覆盖
-
PATCH
用于对资源进行部分修改(资源不存在，会创建新的资源)
-
DELETE
用于删除指定的资源
-
TRACE
请求服务器回显其收到的请求信息，主要用于HTTP请求的测试或诊断
-
CONNECT
可以开启一个客户端与所请求资源之间的双向沟通的通道，它可以用来创建隧道(tunnel) 可以用来访问采用了SSL (HTTPS)协议的站点
3.头部字段
头部字段可以分为4种类型 请求头字段(Request Header Fields) 有关要获取的资源或客户端本身信息的消息头
响应头字段（Response Header Fields） 有关响应的补充信息，比如服务器本身（名称和版本等）的消息头
实体头字段（Entity Header Fields） 有关实体主体的更多信息，比如主体长度（Content-Length）或其MIME类型
通用头字段（General Header Fields） 同时适用于请求和响应消息，但与消息主体无关的消息头
针对不同的服务，也有一些非标准的头
请求头字段
referer头可以防止盗链
q值越大,表示优先级越高 如果不指定q值，默认是1.0 (1.0是最大值)
Range可以用于多线程下载，断点续传
响应头字段
在服务器端设置Content-Disposition让客服端下载文件，而不是简单的访问文件，还可以建议文件的名字，下载的时候就默认填写上建议的名字。
4.状态码
在RFC 2616 10.Status Code Definitions规范中定义
状态码指示HTTP请求是否已成功完成
1xx: 信息 2xx: 成功 3xx: 重定向 4xx: 客户端错误 5xx: 服务器错误
100 Continue
请求的初始部分已经被服务器收到，并且没有被服务器拒绝。客户端应该继续发送剩余的请求，如果请求已经完成，就忽略这个响应 允许客户端发送带请求体的请求前，判断服务器是否愿意接收请求(服务器通过请求头判断) 在某些情况下，如果服务器在不看请求体就拒绝请求时，客户端就发送请求体是不恰当的或低效的
200 OK 请求成功
302 Found:请求的资源被暂时的移动到了由Location头部指定的URL上
例如：登录成功重新定位到一个页面，是由服务器决定的，自定义重定向的页面
这时客服端会重新发送针对这个新的页面的请求
304 Not Modified:说明无需再次传输请求的内容,也就是说可以使用缓存的内容
发现请求的内容刚刚已经发送过给你了，而且数据没有做任何的修改，所以直接可以用缓存的内容
400 Bad Request: 由于语法无效，服务器无法理解该请求
1.请求的格式有问题
2.请求的内容不符，服务器可以自定义返回状态码
401 Unauthorized:由于缺乏目标资源要求的身份验证凭证
403 Forbidden:服务器端有能力处理该请求，但是拒绝授权访问
404 Not Found:服务器端无法找到所请求的资源
405 Method Not Allowed: 服务器禁止了使用当前HTTP方法的请求
当你使用了服务器限制的使用的请求方法，就会返回405
406 Not Acceptable:服务器端无法提供与Accept-Charset以及Accept-Language指定的值相匹配的响应
408 Request Timeout: 服务器想要将没有在使用的连接关闭
一些服务器会在空闲连接上发送此信息，即便是在客户端没有发送任何请求的情况下
500 Internal Server Error:所请求的服务器遇到意外的情况并阻止其执行请求
可以设置回显
501 Not Imiplemented: 请求的方法不被服务器支持，因此无法被处理 服务器必须支持的方法(即不会返回这个状态码的方法)只有GET和HEAD
区分405和501状态码
502 Bad Gateway: 作为网关或代理角色的服务器，从上游服务器(如tomcat) 中接收到的响应是无效的
503 Service Unavailable:服务器尚未处于可以接受请求的状态 通常造成这种情况的原因是由于服务器停机维护或者已超载
5.Form提交
邮箱注册
数据提交
GET提交没有请求体填，请求数据写在url中
POST提交有请求体
表单的常用属性
action:请求的URI method:请求方法(GET、 POST) enctype: POST请求时，请求体的编码方式 application/x-www-form-urlencoded (默认值)
当提交方法Content-Type 变成:multipart/form data（文件上传必须需使用这种编码格式）请求体会发生改变会分成很多部分，用来说明请求体是怎么分割数据的。
当提交图片数据的时候，会有分割线，数据说明，和数据换行，在最后的数据提交完成后会有两个--表明后面没有数据了。
在java中解析请求体可以使用第三方库来解析
Origin 和 Access-Control-Allow-Origin
请求头Content-Type: multipart/form-data; boundary=xxx
6.跨域
前后端分离
前后端分离已成为互联网项目开发的业界标准使用方式，通过nginx+tomcat的方式（也可以中间加一个nodejs）有效的进行解耦，并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。这个步骤是系统架构从猿进化成人的必经之路。 核心思想是前端HTML页面通过AJAX调用后端的RESTFUL API接口并使用JSON数据进行交互。 Web服务器：一般指像Nginx，Apache这类的服务器，他们一般只能解析静态资源； 应用服务器：一般指像Tomcat，Jetty，Resin这类的服务器可以解析动态资源也可以解析静态资源，但解析静态资源的能力没有web服务器好； 一般都是只有web服务器才能被外网访问，应用服务器只能内网访问。 以前的Java Web项目大多数都是Java程序员又当爹又当妈，又搞前端，又搞后端。随着时代的发展，渐渐的许多大中小公司开始把前后端的界限分的越来越明确，前端工程师只管前端的事情，后端工程师只管后端的事情。正所谓术业有专攻，一个人如果什么都会，那么他毕竟什么都不精。大中型公司需要专业人才，小公司需要全才，但是对于个人职业发展来说，前后端需要分离。
前端项目与后端项目是两个项目，放在两个不同的服务器，需要独立部署，两个不同的工程，两个不同的代码库，不同的开发人员。前端只需要关注页面的样式与动态数据的解析及渲染，而后端专注于具体业务逻辑。
同源策略
源（origin）就是协议、域名和端口号,同源就是指协议，域名、端口号要相同。同源策略是浏览器的一个安全功能，不同源的客户端脚本在没有明确授权的情况下，不能读写对方资源。
默认情况下AJAX只能发送给同源的URl
img、script、 link、 iframe、 video、audi o等标签不受同源策略的约束
跨域请求
受前面所讲的浏览器同源策略的影响，不是同源的脚本不能操作其他源下面的对象。想要操作另一个源下的对象是就需要跨域
跨域资源共享
解决AJAX跨域请求的常用方法 CORS (Cross-0rigin Resource Sharing) ，跨域资源共享 CORS的实现需要客户端和服务器同时支持 客户端 所有的浏览器都支持(IE至少是IE10版本) |服务器 需要返回相应的响应头(比如Access-Control-Allow-0rigin) 告知浏览器这是一个允许跨域访问的请求
Cookies
要想访问User需要登录，如果直接访问用户页面会被重定向到登录页面，但是我先访问登录页面，我再提交登录的数据，最后就能请求服务器返回登录后的数据给我。
HTTP的请求是独立、分离的没有联系的，那么服务器怎么知道你登录了呢？
怎么识别登录成功的请求和访问数据的请求是同一个用户呢？
Cookies Session
Cookie 在客户端(浏览器) 存储-些数据， 存储到本地磁盘(硬 盘) 服务器可以返回Cookie交给客户端去存储 Session 在服务器存储一些数据，存储到内存中
登录到服务器
登录失败
登录成功
能够利用session和cookie的技术使得不同页面的数据能够互通，会话跟踪技术。
利用代码创建Session
7.代理服务器
本身不产生内容
处于中间位置，转发上下游的请求和响应
面向下游的客服端：它是服务器
面向上游的服务器：它是客服端
正向代理、反向代理
正向代理：代理的对象为客服端
反向代理：代理的对象是服务器
正向代理作用
隐藏客服端省份
绕过防火墙（突破访问限制）
windows更改代理
Internet访问控制
数据过滤
免费的正向代理 高可用全球免费代理IP库
https://www.kuaidaili.com/free/inah
反向代理的作用
隐藏服务器的身份
安全防护
负载均衡
抓包工具
Fiddler、Charles 等抓包工具的原理：在客服端启动了正向代理服务
需要注意的是
Wireshark的原理是：通过底层的驱动，拦截网卡上流过的数据
代理服务器的头部
Via：追加经过的每一台代理服务器的主机名（或域名） ◼ X-Forwarded-For：追加请求方的IP地址 ◼ X-Real-IP：客户端的真实IP地址
CDN（Content Delivery Network或Content Distribution Network），译为：内容分发网络 利用最靠近每位用户的服务器 更快更可靠地将音乐、图片、视频等资源文件（一般是静态资源）传递给用户
CDN运营商在全国、乃至全球的各个大枢纽城市都建立了机房 部署了大量拥有高存储高带宽的节点，构建了一个跨运营商、跨地域的专用网络 ◼ 内容所有者向CDN运营商支付费用，CDN将其内容交付给最终用户
CDN使用举例
◼ 使用cdn引入jquery
六、网络安全
网络通信中面临的4种安全威胁
截获：窃听通信内容 中断：中断网络通信 篡改：篡改通信内容 伪造：伪造通信内容
1.网络层 ARP欺骗
ARP欺骗（ARP spoofing），又称ARP毒化（ARP poisoning）、ARP病毒、ARP攻击
ARP欺骗可以造成的效果
可让攻击者获取局域网上的数据包甚至可篡改数据包 可让网络上特定电脑之间无法正常通信（例如网络执法官这样的软件） 让送至特定IP地址的流量被错误送到攻击者所取代的地方
ARP欺骗核心步骤举例
假设主机C是攻击者，主机A、B是被攻击者 C只要收到过A、B发送的ARP请求，就会拥有A、B的IP、MAC地址，就可以进行欺骗活动 C发送一个ARP响应给B，把响应包里的源IP设为A的IP地址，源MAC设为C的MAC地址 B收到ARP响应后，更新它的ARP表，把A的MAC地址（IP_A, MAC_A）改为（IP_A, MAC_C） 当B要发送数据包给A时，它根据ARP表来封装数据包的头部，把目标MAC地址设为MAC_C，而非MAC_A 当交换机收到B发送给A的数据包时，根据此包的目标MAC地址（MAC_C）而把数据包转发给C C收到数据包后，可以把它存起来后再发送给A，达到窃听效果。C也可以篡改数据后才发送数据包给A
用一个瞎写的mac来起到欺骗作用
ARP欺骗的防护
静态ARP ◼ DHCP Snooping 网络设备可借由DHCP保留网络上各电脑的MAC地址，在伪造的ARP数据包发出时即可侦测到 ◼ 利用一些软件监听ARP的不正常变动
2.DoS DDoS
DoS攻击（拒绝服务攻击，Denial-of-Service attack） 使目标电脑的网络或系统资源耗尽，使服务暂时中断或停止，导致其正常用户无法访问 ◼ DDoS攻击（分布式拒绝服务攻击，Distributed Denial-of-Service attack）
黑客使用网络上两个或以上被攻陷的电脑作为“僵尸”向特定的目标发动DoS攻击 2018年3月，GitHub遭到迄今为止规模最大的DDoS攻击
◼ DoS攻击可以分为2大类 带宽消耗型：UDP洪水攻击、ICMP洪水攻击 资源消耗型：SYN洪水攻击、LAND攻击
SYN洪水攻击（SYN flooding attack）
攻击者发送一系列的SYN请求到目标，然后让目标因收不到ACK（第3次握手）而进行等待、消耗资源
◼ 攻击方法 跳过发送最后的ACK信息 修改源IP地址，让目标送SYN-ACK到伪造的IP地址，因此目标永不可能收到ACK（第3次握手）
◼ 防护 参考：RFC 4987
LAND攻击（局域网拒绝服务攻击，Local Area Network Denial attack）
通过持续发送相同源地址和目标地址的欺骗数据包，使目标试图与自己建立连接，消耗系统资源直至崩溃 ◼ 有些系统存在设计上的缺陷，允许设备接受并响应来自网络、却宣称来自于设备自身的数据包，导致循环应答 ◼ 防护 大多数防火墙都能拦截类似的攻击包，以保护系统 部分操作系统通过发布安全补丁修复了这一漏洞 路由器应同时配置上行与下行筛选器，屏蔽所有源地址与目标地址相同的数据包
DoS DDoS的防御
防御方式通常为：入侵检测、流量过滤、和多重验证 堵塞网络带宽的流量将被过滤，而正常的流量可正常通过
◼ 防火墙 防火墙可以设置规则，例如允许或拒绝特定通讯协议，端口或IP地址 当攻击从少数不正常的IP地址发出时，可以简单的使用拒绝规则阻止一切从攻击源IP发出的通信 复杂攻击难以用简单规则来阻止，例如80端口遭受攻击时不可能拒绝端口所有的通信，因为同时会阻止合法流量 防火墙可能处于网络架构中过后的位置，路由器可能在恶意流量达到防火墙前即被攻击影响 ◼ 交换机：大多数交换机有一定的速度限制和访问控制能力 ◼ 路由器：和交换机类似，路由器也有一定的速度限制和访问控制能力
黑洞引导
将所有受攻击计算机的通信全部发送至一个“黑洞”（空接口或不存在的计算机地址）或者有足够能力处理洪流 的网络设备商，以避免网络受到较大影响
◼ 流量清洗 当流量被送到DDoS防护清洗中心时，通过采用抗DDoS软件处理，将正常流量和恶意流量区分开 正常的流量则回注回客户网站
3.DNS劫持
DNS劫持，又称为域名劫持 攻击者篡改了某个域名的解析结果，使得指向该域名的IP变成了另一一个IP 导致对相应网址的访问被劫持到另一个不可达的或者假冒的网址 从而实现非法窃取用户信息或者破坏正常网络服务的目的
通过DNS劫持可以将你访问的网址导向博彩网站
为防止DNS劫持，可以考虑使用更靠谱的DNS服务器，比如: 114.114.114.114
谷歌: 8.8.8.8、 8.8.4.4 微软: 4.2.2.1、 4.2.2.2 百度: 180.76.76.76 阿里: 223.5.5.5、 223.6.6.6
在电脑中设置DNS服务器
HTTP劫持：对HTTP数据包进行拦截处理，比如插入JS代码
比如你访问某些网站时，在右下角多了个莫名其妙的弹窗广告
HTTP协议默认是采取明文传输的，因此会有很大的安全隐患 I常见的提高安全性的方法是:对通信内容进行加密后，再进行传输
常见的加密方式有 不可逆 单向散列函数: MD5、SHA等 可逆 对称加密: DES、 3DES、AES等 非对称加密: RSA等 其它 IOS底层原理、IOS签名 混合密码系统 数字签名 证书
HTTP协议的安全问题
HTTP协议默认是采取明文传输的，因此会有很大的安全隐患
七、加解密
encrypt:加密 decrypt:解密 plaintext:明文 ciphertext:密文
为了便于学习，设计4个虚拟人物 Alice、 Bob: 互相通信 Eve:窃听者 Mallory: 主动攻击者
如何防止被窃听
1.单项散列函数
单向散列函数，可以根据根据消息内容计算出散列值 散列值的长度和消息的长度无关，无论消息是1bit、 10M、 100G， 单向散列函数都会计算出固定长度的散列值
根据任意长度的消息，计算出固定长度的散列值 计算速度快，能快速计算出散列值 消息不同，散列值也不同 具备单向性
单向散列函数，也被称为 消息摘要函数(message digest function) 哈希函数(hash function)
输出的散列值，也被称为 消息摘要(message digest) 指纹(fingerprint)
常见的几种单项散列函数
MD4、MD5 产生128bit的散列值，MD就是Message Digest的缩写，目前已经不安全
SHA-1 产生160bi t的散列值，目前已经不安全
SHA-2 SHA-256、 SHA- -384、 SHA-512,散列值长度分别是256bit、384bit、 512bit
SHA-3 全新标准
通过穷举，可以列举出加密的内容
2.防止数据被篡改
通过单项散列函数计算确保数据没有被篡改
在下载某些文件的时候就会有验算的单项散列函数
单项散列函数的应用
密码加密
3.加密解密方式
对称加密
非对称加密
公钥和私钥
对称加密
在对称加密中，加密、解密时使用的是同一个密钥
常见的对称加密算法有 DES 3DES (Triple Data Encryption Algor ithm)
DES
DES是一 种将64bi t明文加密成64bi t密文的对称加密算法，密钥长度是56bit 规格_上来说，密钥长度是64bit,但每隔7bi t会设置-一个用于错误检查的bit,因此密钥长度实质上是56bit 由于DES每次只能加密64bi t的数据，遇到比较大的数据，需要对DES加密进行迭代(反复) 目前已经可以在短时间内被破解，所以不建议使用
3DES
3DES,将DES重复3次所得到的一种密码算法，也叫做3重DES 三重DES并不是进行三次DES加密(加密>加密>加密) 而是加密(Encryption) → 解密(Decryption) > 加密(Encryption) 的过程
目前还被- -些银行等机构使用，但处理速度不高，安全性逐渐暴露出问题
3个密钥都是不同的，也称为DES-EDE3
AES
(Advanced Encryption Standard)
取代DES成为新标准的一种对称加密算法，又称Rijndael加密法 AES的密钥长度有128、192、 256bit三种 目前AES，已经逐步取代DES、3DES, 成为首选的对称加密算法 一般来说，我们也不应该去使用任何自制的密码算法，而是应该使用AES 它经过了全世界密码学家所进行的高品质验证工作
MD5加密 md5加密,sha1加密--md5在线解密 MD5解密 md5在线解密破解,md5解密加密 其它加密 https://www.soison.com/encryptdes.html MD5在线加密 - 站长工具
4.密钥配送问题
对称加密
对称加密一定会遇到密钥配送问题
如果Alice将使用对称加密过的消息发给了Bob 只有将密钥发送给Bob，Bob才 能完成解密 在发送密钥过程中 可能会被Eve窃取密钥 最后Eve也能完成解密
解决密钥配送问题
-
事先共享密钥(比如私下共享)
-
密钥分配中心(Key Distribution Center, 简称KDC)
-
Diffie-Hellman密钥交换
-
非对称加密
非对称加密
在非对称加密中，密钥分为加密密钥、解密密钥2种，它们并不是同一个密钥
加密密钥:一般是公开的，因此该密钥称为公钥(public key)
因此，非对称加密也被称为公钥密码(Public-key Cryptography)
解密密钥:由消息接收者自己保管的，不能公开，因此也称为私钥(private key)
公钥和私钥的使用
公钥私钥
公钥和私钥是一 一对应的，不能单独生成 一对公钥和私钥统称为密钥对(key pair)
由公钥加密的密文，必须使用与该公钥对应的私钥才能解密
由私钥加密的密文，必须使用与该私钥对应公钥的才能解密
非对称加密: 复杂->安全->加密解密速度慢 对称加密: 简单->不安全->加密解密速度快
◼ 由消息的接收者，生成一对公钥、私钥 ◼ 将公钥发给消息的发送者 ◼ 消息的发送者使用公钥加密消息 ◼ 非对称加密的加密解密速度比对称加密要慢
5.混合密码系统
(Hybrid Cryptosystem)
对称加密的缺点 不能很好地解决密钥配送问题(密钥会被窃听)
非对称加密的缺点 加密解密速度比较慢
混合密码系统:是将对称加密和非对称加密的优势相结合的方法 解决了非对称加密速度慢的问题 并通过非对称加密解决了对称加密的密钥配送问题
网络上的密码通信所用的SSL/ TLS都运用了混合密码系统
加密
会话密钥(session key) 为本次通信随机生成的临时密钥 作为对称加密的密钥，用于加密消息，提高速度
加密步骤(发送消息)
-
首先，消息发送者要拥有消息接收者的公钥
-
生成会话密钥，作为对称加密的密钥，加密消息
-
用消息接收者的公钥，加密会话密钥
-
将前2步生成的加密结果，-并发给消息接收者
发送出去的内容包括 用会话密钥加密的消息(加密方法:对称加密) 用公钥加密的会话密钥(加密方法:非对称加密)
解密
解密步骤(收到消息)
-
消息接收者用自己的私钥解密出会话密钥
-
再用第①步解密出来的会话密钥，解密消息
加密解密流程
Alice >>>>>> Bob 发送过程(加密过程)
-
Bob先生成一对公钥、私钥
-
Bo b把公钥共享给Alice
-
Alice随机生成一个会话密钥(临时密钥)
-
Alice用会话密钥加密需要发送的消息(使用的是对称加密)
-
Alice用Bob的公钥加密会话密钥(使用的是非对称加密)
-
Alice把第④、⑤步的加密结果，一并发送给Bob
接收过程(解密过程) Bob利用自己的私钥解密会话密钥(使用的是非对称加密算法进行解密) Bob利用会话密钥解密发送过来的消息(使用的是对称加密算法进行解密)
数字签名
解决方案 -----》数字签名
在数字签名技术中，有以下2种行为
生成签名 由消息的发送者完成，通过“签名密钥”生成
验证签名 由消息的接收者完成，通过“验证密钥”验证
如何能保证这个签名是消息发送者自己签的？ 用消息发送者的私钥进行签名
如果有人篡改了消息内容或签名内容，会是什么结果？ 签名验证失败，证明内容被篡改了
数字签名不能保证机密性？ 数字签名的作用不是为了保证机密性，仅仅是为了能够识别内容有没有被篡改
数字签名的作用
-
确认消息的完整性
-
识别消息是否被篡改
-
防止消息发送人否认
总结
公钥的合法性
如果遭遇了中间人攻击，那么公钥将可能是伪造的
◼ 如何验证公钥的合法性？ 证书
6.证书(Certificate)
说到证书 首先联想到的是驾驶证、毕业证、英语四六级证等等，都是由权威机构认证的
密码学中的证书，全称叫公钥证书（Public-key Certificate，PKC），跟驾驶证类似 里面有姓名、邮箱等个人信息，以及此人的公钥 并由认证机构（Certificate Authority，CA）施加数字签名
◼ CA就是能够认定“公钥确实属于此人”并能够生成数字签名的个人或者组织 有国际性组织、政府设立的组织 有通过提供认证服务来盈利的企业 个人也可以成立认证机构
各大CA的公钥，默认已经内置在浏览器和操作系统中
证书的注册和下载
查看电脑中的证书
-
Windows键 + R >>> 输入mmc
-
文件 >>> 添加/删除管理单元
-
证书 >>> 添加 >>> 我的用户账户 >>> 完成 >>> 确定
八、HTTPS
1.简介
HTTPS（HyperText Transfer Protocol Secure），译为：超文本传输安全协议 常称为HTTP over TLS、HTTP over SSL、HTTP Secure 由网景公司于1994年首次提出
HTTP不安全的连接
HTTPS的默认端口号是443 (HTTP是80)
输入百度一下，你就知道 重定向到HTTPS连接
HTTPS是在HTTP的基础上使用SSL/TLS来加密报文，对窃听和中间人攻击提供合理的防护
SSL/TLS也可以用在其他协议上，比如 FTP → FTPS SMTP → SMTPS
2.SSL/TLS
TLS（Transport Layer Security），译为：传输层安全性协议 前身是SSL（Secure Sockets Layer），译为：安全套接层
历史版本信息 SSL 1.0：因存在严重的安全漏洞，从未公开过 SSL 2.0：1995年，已于2011年弃用（RFC 6176） SSL 3.0：1996年，已于2015年弃用（RFC 7568） TLS 1.0：1999年（RFC 2246） TLS 1.1：2006年（RFC 4346） TLS 1.2：2008年（RFC 5246） TLS 1.3：2018年（RFC 8446） TLS的RFC文档编号都是以46结尾
工作在应用层和传输层之前
3.OpenSSL
OpenSSL是SSL/TLS协议的开源实现，始于1998年，支持Windows、Mac、Linux等平台 Linux、Mac一般自带OpenSSL Windows下载安装OpenSSL：Win32/Win64 OpenSSL Installer for Windows - Shining Light Productions ◼ 常用命令 生成私钥：openssl genrsa -out mj.key 生成公钥：openssl rsa -in mj.key -pubout -out mj.pem ◼ 可以使用OpenSSL构建一套属于自己的CA，自己给自己颁发证书，称为“自签名证书”
HTTPS通信过程
总的可以分为3大阶段
-
TCP的3次握手
-
TLS的连接
-
HTTP请求和响应
4.TSL1.2连接
①Client Hello TLS的版本号 支持的加密组件(Cipher Suite)列表 加密组件是指所使用的加密算法及密钥长度等 一个随机数(Client Random)
②Server Hello TLS的版本号 选择的加密组件 是从接收到的客户端加密组件列表中挑选出来的 一个随机数(Server Random)
③Certificate 服务器的公钥证书(被CA签名过的)
④Server Key Exchange 用以实现ECDHE算法的其中一个参数(Server Params) ECDHE是一种密钥交换算法 为了防止伪造，Server Params经过了服务器私钥签名
⑤Server Hello Done 告知客户端:协商部分结束
目前为止，客户端和服务器之间通过明文共享了 Client Random、 Server Random、 Server Params 而且，客户端也已经拿到了服务器的公钥证书，接下来，客户端会验证证书的真实有效性
⑥Client Key Exchange 用以实现ECDHE算法的另一个参数(Client Params)
目前为止，客户端和服务器都拥有了ECDHE算法需要的2个参数: Server Params、Client Params 客户端、服务器都可以使用ECDHE算法根据Server Params、Client Params计算出一个新的随机密钥串: Pre-master secret然后结合Client Random、Server Random、Pre-master secret生成一个主密钥 最后利用主密钥衍生出其他密钥:客户端发送用的会话密钥、服务器发送用的会话密钥等
⑦Change Cipher Spec 告知服务器:之后的通信会采用计算出来的会话密钥进行加密
⑧Finished 包含连接至今全部报文的整体校验值(摘要) 加密之后发送给服务器 这次握手协商是否成功，要以服务器是否能够正确解密该报文作为判定标准
⑨Change Cipher Spec Finished 到此为止，客户端服务器都验证加密解密没问题，握手正式结束 后面开始传输加密的HTTP请求和响应
5.wireshark解密HTTPS
设置环境变量SSLKEYLOGFILE（浏览器会将key信息导出到这个文件）
设置完成后，最好重启一下操作系统 在Wireshark中选择这个文件 编辑→首选项→Protocols→TLS
wireshark操作
◼ 如果环境变量不管用，可以直接设置浏览器的启动参数（下图是使用了Rolan进行启动)
启动参数中添加--ssl-key-log-file=F:/log\ssl.log
6.配置HTTPS生成证书
环境：Tomcat9.0.34、JDK1.8.0_251 ◼ 首先，使用JDK自带的keytool生成证书（一个生成免费证书的网站： Free SSL Certificates Provider and ACME Tools – freessl.org） keytool -genkeypair -alias mj -keyalg RSA -keystore F:/mj.jks
将证书*.jks文件放到TOMCAT_HOME/conf目录下
修改TOMCAT_HOME/conf/server.xml中的Connector
九、HTTP的升级改进
1.HTTP协议的不足(HTTP/1.1)
同一时间，一个连接只能对应一个请求 针对同一个域名，大多数浏览器允许同时最多6个并发连接
只允许客户端主动发起请求 一个请求只能对应一个响应
同一个会话的多次请求中，头信息会被重复传输 通常会给每个传输增加500~800字节的开销 如果使用 Cookie，增加的开销有时会达到上千字节
2.SPDY
SPDY (speedy的缩写)，是基于TCP的应用层协议,它强制要求使用SSL/TLS 2009年11月，Google宣布将SPDY作为提高网络速度的内部项目
SPDY与HTTP的关系 SPDY并不用于取代HTTP，它只是修改了HTTP请求与响应的传输方式 只需增加一个SPDY层，现有的所有服务端应用均不用做任何修改 SPDY是HTTP/2的前身 2015年9月，Google宣布移除对SPDY的支持，拥抱HTTP/2
3.HTTP/2
HTTP/1.1和HTTP/2速度对比
HTTP/2 technology demo HTTP/2: the Future of the Internet | Akamai
◼ HTTP/2在底层传输做了很多的改进和优化，但在语意上完全与HTTP/1.1兼容 比如请求方法（如GET、POST）、Status Code、各种Headers等都没有改变 因此，要想升级到HTTP/2 开发者不需要修改任何代码 只需要升级服务器配置、升级浏览器
二进制帧
HTTP/2采用二进制格式传输数据，而非HTTP/1.1的文本格式
二进制格式在协议的解析和优化扩展上带来更多的优势和可能
建立双向字节流
数据流：已建立的连接内的双向字节流，可以承载一条或多条消息 所有通信都在一个TCP连接上完成，此连接可以承载任意数量的双向数据流
消息：与逻辑HTTP请求或响应消息对应，由一系列帧组成
帧：HTTP/2通信的最小单位，每个帧都包含帧头（会标识出当前帧所属的数据流） 来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装
多路复用
客户端和服务器可以将 HTTP消息分解为互不依赖的帧，然后交错发送，最后再在另一端把它们重新组装起来 ◼ 并行交错地发送多个请求，请求之间互不影响 ◼ 并行交错地发送多个响应，响应之间互不干扰 ◼ 使用一个连接并行发送多个请求和响应 ◼ 不必再为绕过HTTP/1.1限制而做很多工作 比如image sprites、合并CSS\JS、内嵌CSS\JS\Base64图片、域名分片等
优先级
HTTP/2 标准允许每个数据流都有一个关联的权重和依赖关系 可以向每个数据流分配一个介于1至256之间的整数 每个数据流与其他数据流之间可以存在显式依赖关系
客户端可以构建和传递“优先级树”，表明它倾向于如何接收响应
服务器可以使用此信息通过控制CPU、内存和其他资源的分配设定数据流处理的优先级 在资源数据可用之后，确保将高优先级响应以最优方式传输至客户端
应尽可能先给父数据流分配资源 同级数据流（共享相同父项）应按其权重比例分配资源
① A、B依赖于隐式“根数据流”，A获得的资源比例是12/16，B获得的资源比例是4/16 ② D依赖于根数据流，C依赖于D，D应先于C获得完整资源分配 ③ D应先于C获得完整资源分配，C应先于A和B获得完整资源分配，B获得的资源是A所获资源的1/3 ④ D应先于E和C获得完整资源分配，E和C应先于A和B获得相同的资源分配，B获得的资源是A所获资源的1/3
头部压缩
HTTP/2使用HPACK压缩请求头和响应头 可以极大减少头部开销，进而提高性能
早期版本的HTTP/2和SPDY使用 zlib压缩
-
可以将所传输头数据的大小减小85%~88%
-
但在2012年夏天，被攻击导致会话劫持
-
后被更安全的HPACK取代
服务器推送
服务器可以对一个客户端请求发送多个响应
除了对最初请求的响应外，服务器还可以向客户端推送额外资源，而无需客户端额外明确地请求
问题
-
队头堵塞
-
握手延迟
RTT(Round Trip Time): 往返延迟，可以简单理解为通信一来一回的时间
4.HTTP/3
Google觉得HTTP/2仍然不够快，于是就有了HTTP/3
-
HTTP/3由Google开发，弃用TCP协议，改为使用基于UDP协议的QUIC协议实现
-
QUIC（Quick UDP Internet Connections），译为：快速UDP网络连接，由Google开发，在2013年实现
-
于2018年从HTTP-over-QUIC改为HTTP/3
HTTP/3基于UDP，如何保证可靠传输？
由QUIC来保证
为何Google不开发一个新的不同于TCP、UDP的传输层协议？
为什么不这么做？
因为
目前世界上的网络设备基本只认TCP、UDP 如果要修改传输层，意味着操作系统的内核也要修改 另外，由IETF标准化的许多TCP新特性都因缺乏广泛支持而没有得到广泛的部署或使用 因此，要想开发并应用一个新的传输层协议，是极其困难的一件事情
连接迁移
TCP基于4要素（源IP、源端口、目标IP、目标端口）
切换网络时至少会有一个要素发生变化，导致连接发生变化 当连接发生变化时，如果还使用原来的TCP连接，则会导致连接失败，就得等原来的连接超时后重新建立连接 所以我们有时候发现切换到一个新网络时，即使新网络状况良好，但内容还是需要加载很久 如果实现得好，当检测到网络变化时立刻建立新的TCP连接，即使这样，建立新的连接还是需要几百毫秒的时间
◼ QUIC的连接不受4要素的影响，当4要素发生变化时，原连接依然维持 QUIC连接不以4要素作为标识，而是使用一组Connection ID（连接ID）来标识一个连接 即使IP或者端口发生变化，只要Connection ID没有变化，那么连接依然可以维持 比如 当设备连接到Wi-Fi时，将进行中的下载从蜂窝网络连接转移到更快速的Wi-Fi连接 当Wi-Fi连接不再可用时，将连接转移到蜂窝网络连接
操作系统内核、CPU负载
◼ 据Google和Facebook称，与基于TLS的HTTP/2相比，它们大规模部署的QUIC需要近2倍的CPU使用量 Linux内核的UDP部分没有得到像TCP那样的优化，因为传统上没有使用UDP进行如此高速的信息传输 TCP和TLS有硬件加速，而这对于UDP很罕见，对于QUIC则基本不存在
随着时间的推移，相信这个问题会逐步得到改善，技术得到更新完善后问题也会有解决的方案
十、其他协议
Socket：一套网络编程 API，利用它可以建立网络连接
Socket类、ServerSocket类
HTTP请求的特点：通信只能由客户端发起。所以，早期很多网站为了实现推送技术，所用的技术都是轮询 典型的请求问答
轮询是指由浏览器每隔一段时间（如每秒）向服务器发出HTTP请求，然后服务器返回最新的数据给客户端 为了能更好的节省服务器资源和带宽，并且能够更实时地进行通讯，HTML5规范中出现了WebSocket协议
推送技术：体育赛事直播，聊天，股票基金价格
1.WebSocket
是基于TCP的支持全双工通信的应用层协议
WebSocket，是基于TCP的支持全双工通信的应用层协议 在2011年由IETF标准化为RFC 6455，后由RFC 7936补充规范 客户端、服务器，任何一方都可以主动发消息给对方
WebSocket的应用场景很多 社交订阅、股票基金报价、体育实况更新、多媒体聊天、多玩家游戏等
WebSocket和HTTP属于平级关系，都是应用层的协议 其实TCP本身就是支持全双工通信的（客户端、服务器均可主动发消息给对方） 只是HTTP的“请求-应答模式”限制了TCP的能力
WebSocket使用80（ws://）、443（wss://）端口，可以绕过大多数防火墙的限制 ws://example.com/wsapi wss://secure.example.com/wsapi
与HTTP不同的是，WebSocket需要先建立连接 这就使得WebSocket成为一种有状态的协议，之后通信时可以省略部分状态信息 而HTTP请求可能需要在每个请求都额外携带状态信息（如身份认证等）
建立连接
WebSocket需要借助HTTP协议来建立连接（也叫作握手，Handshake） 由客户端（浏览器）主动发出握手请求
随机字符简单的完成拼接
WebSocket体验和演示 https://www.websocket.org/echo.html ◼ W3C标准化了一套WebSocket API，可以直接使用JS调用
2.WebService
WebService,译为: Web服务,是一-种跨编程语言和跨操作系统平台的远程调用技术标准
WebService使用场景举例 天气预报、手机归属地查询、航班信息查询、物流信息查询等 比如天气预报，是气象局把自己的服务以WebService形式暴露出来，让第三方程序可以调用这些服务功能 WebXml | WEB服务 | WEB服务解决方案和技术支持 | 网站设计 | 域名交易 ◼ 事实上，WebService完全可以用普通的Web API取代（比如HTTP + JSON） 现在很多企业的开放平台都是直接采用Web API
快递物流，比如京东天猫上面买的东西
事实上，WebService完全可以用普通的Web API取代（比如HTTP + JSON） 现在很多企业的开放平台都是直接采用Web API
核心概念
SOAP（Simple Object Access Protocol），译为：简单对象访问协议很多时候，SOAP = HTTP + XML WebService使用SOAP协议来封装传递数据 WSDL（Web Services Description Language），译为：Web服务描述语言 一个XML文档，用以描述WebService接口的细节（比如参数、返回值等） 一般在WebService的URL后面跟上?wsdl获取WSDL信息 比如：http://ws.webxml.com.cn/WebServices/WeatherWS.asmx?wsdl
3.RESTful
◼ 的全称是： REpresentational State Transfer 译为“表现层状态转移” ◼ 是一种互联网软件架构设计风格 定义了一组用于创建 服务的约束 符合 架构的 服务，称为 服务
使用HTTP的方法表达动作
一个资源连接到其他资源，使用子资源的形式 GET /users/6/cars/88 POST /users/8/cars
API版本化 mj . com/v1/users mj. com/ v2/users/66 返回JSON格式的数据入 发生错误时，不要返回200状态码
4.HTTPDNS
HTTPDNS是基于HTTP协议向DNS服务器发送域名解析请求
-
替代了基于DNS协议向运营商Local DNS发起解析请求的传统方式
-
可以避免Local DNS造成的域名劫持和跨网访问问题
-
常用在移动互联网中(比如在Android、 iOS开发中)
市面上已经有现成的解决方案 腾讯云：移动解析HttpDNS_移动互联网域名解析_域名防劫持 - 腾讯云 阿里云：- 帮助中心 - 阿里云 ◼ 移动端集成相关的SDK即可使用HTTPDNS服务
5.FTP
◼ FTP（File Transport Protocol），译为：文件传输协议，RFC 959定义了此规范，是基于TCP的应用层协议 在RFC 1738中有定义，FTP的URL格式为：ftp://[user[:password]@]host[:port]/url-path
◼ FTP有2种连接模式：主动（Active）和被动（Passive）
◼ 不管是哪种模式，都需要客户端和服务器建立2个连接 ① 控制连接：用于传输状态信息（命令，cmd） ② 数据连接：用于传输文件和目录信息（data）
FTP主动模式
① 客户端打开一个随机的命令端口 端口号大于1024，假设为N 同时连接至服务器的命令端口21 ② 客户端开始监听N+1数据端口 同时向服务器发送一个Port命令给服务器的命令端口21 此命令告诉服务器 ✓ 客户端正在监听的数据端口N+1 ✓ 并且已准备好从此端口接收数据 ③ 服务器打开20号数据端口，并且创建和客户端数据端口（N+1）的连接
FTP被动模式
客户端通过两个随机的端口与服务器建立连接 命令端口N 数据端口N+1 ① 客户端的命令端口N用于连接服务器的命令端口21 ② 客户端通过命令端口N发送PASV命令给服务器的命令端口21 ③ 服务器打开一个随机的数据端口P，并告知客户端该端口号P ④ 客户端数据端口N+1发起与服务器数据端口P的连接
6.邮件相关协议
◼ 发邮件使用的协议 SMTP（Simple Mail Transfer Protocol），译为：简单邮件传输协议 ✓ 基于TCP，标准参考RFC 5321 ✓ 服务器默认使用25端口，SSL/TLS使用465端口
◼ 收邮件使用的协议 POP（Post Office Protocol），译为：邮局协议 ✓ 基于TCP，最新版是POP3，标准参考RFC 1939 ✓ 服务器默认使用110端口，SSL/TLS使用995端口
IMAP（Internet Message Access Protocol），译为：因特网信息访问协议 ✓ 基于TCP，最新版是IMAP4，标准参考RFC 3501 ✓ 服务器默认使用143端口，SSL/TLS使用993端口
POP vs IMAP
POP的特点
-
客户端连接服务器时，将会从服务器下载所有邮件
-
可以设置下载完后，立即或一-段时间后删除服务器邮件
-
客户端的操作(比如删除邮件、移动到文件夹)不会跟服务器同步
-
每个客户端都是独立的，都可以获得其自己的电子邮件副本
IMAP的特点
-
客户端连接服务器时，获取的是服务器上邮件的基本信息，并不会下载邮件
-
等打开邮件时，才开始下载邮件
-
客户端的操作(比如删除邮件、移动到文件夹)会跟服务器同步
-
所有客户端始终会看到相同的邮件和相同的文件夹
十一、补充
1.VPN
VPN (Virtual Private Network),，译为:虚拟私人网络 它可以在公共网络上建立专用网络，进行加密通讯
-
提高上网的安全性
-
保护公司内部资料
-
隐藏上网者的身份
-
突破网站的地域限制 有些网站针对不同地区的用户展示不同的内容
-
突破网络封锁 因为有GFW的限制，有些网站在国内上不了 Great Firewall of China 中国长城防火墙
和代理的区别
软件 VPN一般需要安装VPN客户端软件 代理不需要安装额外的软件
安全性 VPN默认会对数据进行加密 代理默认不会对数据进行加密（数据最终是否加密取决于使用的协议本身）
费用 一般情况下，VPN比代理贵
实现原理
VPN的实现原理是：使用了隧道协议（Tunneling Protocol） 常见的VPN隧道协议有 PPTP（Point to Point Tunneling Protocol）：点对点隧道协议 L2TP（Layer Two Tunneling Protocol）：第二层隧道协议 IPsec（Internet Protocol Security）：互联网安全协议 SSL VPN（如OpenVPN）
tcpdump是Linux平台的抓包分析工具，Windows版本是WinDump ◼ 使用手册 Man page of TCPDUMP ◼ 不错的教程 A tcpdump Tutorial with Examples — 50 Ways to Isolate Traffic - Daniel Miessler
2.网络爬虫
简介
（Web Crawler），也叫做网络蜘蛛（Web Spider） 模拟人类使用浏览器操作页面的行为，对页面进行相关的操作 常用爬虫工具：Python的Scrapy框架
jar包 https://jsoup.org/packages/jsoup-1.13.1.jar https://mirror.bit.edu.cn/apache//commons/io/binaries/commons-io-2.8.0-bin.zip 爬取目标：应用市场
利用java代码实现爬虫功能
获取爬取的png图标
约定俗成
◼ robots.txt是存放于网站根目录下的文本文件，比如https://www.baidu.com/robots.txt 用来告诉爬虫：哪些内容是不应被爬取的，哪些是可以被爬取的 因为一些系统中的URL是大小写敏感的，所以robots.txt的文件名应统一为小写 ◼ 它并不是一个规范，而只是约定俗成的，所以并不能保证网站的隐私 只能防君子，不能防小人 无法阻止不讲“武德”的年轻爬虫爬取隐私信息
3.无线AP
无线接入点
类似于蜂窝的发射基站，蜂窝网络，通过无线AP发射信号使设备进行连接
4.缓存（cache）
浏览器将请求的数据缓存到内存中或者硬盘里面，在请求发生的时候将缓存的数据拿出来使用
实际上，HTTP的缓存机制远远比上图的流程要复杂 通常会缓存的情况是: GET请求+静态资源(比如HTML、CSS、 JS. 图片等) Ctrl + F5:可以强制刷新缓存
详细的缓存请求流程
请求头
◼ 优先级：Pragma > Cache-Control > Expires Pragma：作用类似于Cache-Control，HTTP/1.0的产物 ◼ Expires：缓存的过期时间（GMT格式时间），HTTP/1.0的产物 ◼ Cache-Control：设置缓存策略 no-storage：不缓存数据到本地 public：允许用户、代理服务器缓存数据到本地 private：只允许用户缓存数据到本地 max-age：缓存的有效时间（多长时间不过期），单位秒
单位为秒有一定的缺陷，如果在一秒内请求的数据发生了变化，那么数据就不会被更新
no-cache：每次需要发请求给服务器询问缓存是否有变化，再来决定如何使用缓存 ◼ 优先级：Pragma > Cache-Control > Expires ◼ Last-Modified：资源的最后一次修改时间
通过最后一次的修改时间，来推断是否要修更新内容
◼ ETag：资源的唯一标识（根据文件内容计算出来的摘要值）
相当于单项散列函数，能够确定文件的荣是否有更改，如果内容有更改计算出来的摘要值也会被改变
◼ 优先级：ETag > Last-Modified
响应头
◼ If-None-Match 如果上一次的响应头中有ETag，就会将ETag的值作为请求头的值 如果服务器发现资源的最新摘要值跟If-None-Match不匹配，就会返回新的资源（200 OK） 否则，就不会返回资源的具体数据（304 Not Modified） ◼ If-Modified-Since 如果上一次的响应头中没有ETag，有Last-Modified，就会将Last-Modified的值作为请求头的值 如果服务器发现资源的最后一次修改时间晚于If-Modified-Since，就会返回新的资源（200 OK） 否则，就不会返回资源的具体数据（304 Not Modified）
Last-Modified VS ETag
◼ Last-Modified的缺陷 只能精确到秒级别，如果资源在1秒内被修改了，客户端将无法获取最新的资源数据 如果某些资源被修改了（最后一次修改时间发生了变化），但是内容并没有任何变化 ✓ 会导致相同数据重复传输，没有使用到缓存 ◼ ETag可以办到 只要资源的内容没有变化，就不会重复传输资源数据 只要资源的内容发生了变化，就会返回最新的资源数据给客户端
5.IPV6
来自于网络层的协议
◼ IPv6（Internet Protocol version 6），译为：网际协议第6版 用它来取代IPv4主要是为了解决IPv4地址枯竭问题，同时它也在其他方面对于IPv4有许多改进 然而长期以来IPv4在互联网流量中仍占据主要地位，IPv6的使用增长缓慢 在2019年12月，通过IPv6使用Google服务的用户百分率首次超过30% ✓ 因为需要设备、操作系统内核升级支持IPv6 ◼ IPv6采用128位的地址，而IPv4使用的是32位 支持2的128次方（约3.4 ∗ 1038 ）个地址 就以地球人口70亿人计算，每人平均可分得约4.86 ∗ 1028个IPv6地址 ◼ IPv6地址为128bit，每16bit一组，共8组 ◼ 每组以冒号“:”隔开，每组以4位十六进制方式表示 例如2001:0db8:86a3:08d3:1319:8a2e:0370:7344 ◼ 类似于IPv4的点分十进制，同样也存在点分十六进制的写法 2.0.0.1.0.d.b.8.8.5.a.3.0.8.d.3.1.3.1.9.8.a.2.e.0.3.7.0.7.3.4.4
IPV6的报文格式
有40字节的固定首部
IPV4和IPV6报文的比较
黄色的内容表示从IPV4保留到IPV6的数据，蓝色的部分表现从IPV4更改名字或者区域的数据，红色的部分表示到IPV6后消失的数据，绿色的部分表示IPV6新增的数据
Version（占4bit，0110）：版本号 ◼ Traffic Class（占8bit）：交通类别 指示数据包的类别或优先级，可以帮助路由器根据数据包的优先级处理流量 如果路由器发生拥塞，则优先级最低的数据包将被丢弃 ◼ Payload Length（占16bit）：有效负载长度 最大值65535字节 包括了扩展头部、上层（传输层）数据的长度 Hop Limit（占8bit）：跳数限制 与IPv4数据包中的TTL相同 ◼ Source Address（占128bit）：源IPv6地址 ◼ Destination Address（占128bit）：目的IPv6地址 ◼ Flow Label（占20bit）：流标签 指示数据包属于哪个特定序列（流） 用数据包的源地址、目的地址、流标签标识一个流
Next Header 获取下一个扩展头部
6.即时通信
（Instant Messaging，简称IM），平时用的QQ、微信，都属于典型的IM应用 ◼ 国内的IM开发者社区 即时通讯网 - 即时通讯开发者社区! ◼ IM云服务 网易云信、腾讯云、环信等 ◼ 常用的协议 XMPP、MQTT、自定义协议 ◼../AppData/Roaming/Typora/typora-user-images/image-20211026211810866.png
XMPP通过不同的端口来访问服务器
特点 使用XML格式进行传输，体积较大 比较成熟的IM协议，开发者接入方便 MQTT（Message Queuing Telemetry Transport），译为：消息队列遥测传输 基于TCP，默认端口1883、8883（带SSL/TLS） ◼ 特点 开销很小，以降低网络流量，信息冗余远小于XMPP 不是专门为IM设计的协议，很多功能需要自己实现 很多人认为MQTT是最适合物联网（IoT，Internet of Things）的网络协议
7.流媒体
（Streaming Media），又叫流式媒体 是指将一连串的多媒体数据压缩后，经过互联网分段发送数据，在互联网上即时传输影音以供观赏的一种技术 此技术使得资料数据包得以像流水一样发送，不使用此技术，就必须在使用前下载整个媒体文件
将test.mp4分块发送，客服端拿到一小段就可以播放，一边传输一边播放。
RTP（Real-Time Transport Protocol），译为：实时传输协议 参考：RFC 3550、RFC 3551，基于UDP ◼ RTCP（Real-Time Transport Control Protocol），译为：实时传输控制协议 参考：RFC 3550，基于UDP，使用RTP的下一个端口 ◼ RTSP（Real-Time Streaming Protocol），译为：实时流协议，参考：RFC 7820 基于TCP、UDP的554端口 ◼ RTMP（Real-Time Messaging Protocol），译为：实时消息传输协议，由Adobe公司出品 默认基于TCP的1935端口 ◼ HLS（HTTP Live Streaming），基于HTTP的流媒体网络传输协议，苹果公司出品，参考：RFC 8216
8.总结
客户端->交换机->路由器->路由器->路由器->交换机->服务器
1.浏览器输入百度一下，你就知道 2.询问DNS获取百度服务器的IP地址 3.发送HTTP请求(调用Socket API发送请求 4.建立连接（TCP3次握手） 5.发送HTTP请求报文 6.返回HTTP响应报文
个人总结：
通过这次网络协议的学习，让我更加深入的理解到了各个网络层中的协议和作用，也更多的学习到了数据的传输原理，在针对网络安全的学习网络协议的过程中，讲到了ARP欺骗、DDoS、DNS劫持、中间人攻击等，更加深入的了解到协议中的安全内容，也学会了怎么去做好笔记，分类，和做思维导图。这一次收获丰富，但作为一个初学者仍有很多的不足，学习时间的安排和效率，复习和专注都需要做到更好。
1216
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
