1、免责声明
本公众号提供的工具、教程、学习路线、精品文章均为原创或互联网收集，旨在提高网络安全技术水平为目的，只做技术研究，谨遵守国家相关法律法规，请勿用于违法用途。
2、内容速览
UDP和TCP
<1>UDP协议
UDP协议端格式：
16位UDP校验和作用：类似于藏头诗，双方约定好的校验数据，进行数据校验
UDP的特性：
1.无连接：没有建立连接就发数据
2.不可靠：没有类似TCP保证数据传输的安全机制，（连接管理机制，确认应答机制，超时机制 ，）效率更高。
3.面向数据报：只能一次接收（系统级别的操作：调用系统函数）
4.没有发送缓冲区（发了消息就不管），有接收缓冲区
5.数据最大为64k
发送缓冲区：主机1发送完数据，发出之后就不管了 接收缓冲区：如果发送端调用一次sendto, 发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom, 每次接收10个字节; 所以，接收数据的时候，发送100个字节，系统读取只调用一次，但是可以读取多次发来的其他100字节。但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了, 再到达的UDP数据就会被丢弃;
<2>TCP协议(可靠的传输协议)
(1)TCP相关概念
TCP协议：可靠的传输协议，安全，效率(有连接的可靠传输协议) 设计TCP协议的理念：非100%安全，保证可承受范围内的安全，尽可能的提高网络传输数据的效率 TCP协议端格式：
六位标志位：
URG: 紧急指针是否有效
ACK: 确认号是否有效
PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段 SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段 重点掌握ACK,SYN,FIN
(2)确认应答机制
主机A发送数据给主机B，每个数据都带了数据序号,主机B返回ACK应答 每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你从哪里开始发
作用：
1.保证安全：保证‘我’发送的消息，对方必须确认并恢复
2.保证多条数据确认信息的安全（告诉发送者，这次回应是对哪些数据，下次数据发送应该从什么时候开始）
(3)超时重传机制(安全机制)
超时重传机制触发：主机A发送数据给主机B，如果主机A在一个特定的时间间隔内没有收到来自主机B的确认应答，就会进行数据重发。
没有收到确认应答的情况：
1.主机A的数据报在发送的过程中丢了。
2.主机B的ACK应答丢了
超时时间的确定：TCP会根据当时的网络状态，动态的计算数据发送的速度，得到单次数据报发送的最大生存时间（MSL），超时时间即为（2MSL）
(4)连接管理机制（安全机制）
流程图：
1.建立连接------>TCP三次握手:
TCP------>三次握手的流程
1.主机A发送syn到主机B，要求建立a到b的连接。此时主机A的状态为syn_sent 2.主机B回复ack syn（这里的ack和syn数据报本来是两个，但是仅标志位不同，所以可以合并,为什么不是四次的原因），要求建立b到a的连接，主机B的状态为syn_rcvd 3.主机A回复第2步syn的ack。主机A的状态为established，建立A到B的连接 主机B接收到第3步的数据报，建立B到A 的连接，主机B的状态置为established
TCP------>三次握手中的问题：
1.syn为什么有两个？双方的连接状态会持续，且连接是有方向的
2.第二步中，为什么是ack syn？本质上是一个发ack应答，一个发syn请求，而且是方向一致的两个数据报，可以合并
3.第三步中，ack确认应答哪个？应答第二步的syn
2.断开连接------>TCP四次挥手:
TCP------>四次挥手的流程
1.主机A发送fin到主机B，请求关闭a到b的连接
2.主机B回复ack，主机B的状态置为close_wait
3.主机B发送fin到主机A，请求关闭b到a的连接
4.值即A回复ack（第三步的fin），状态置为time_wait 主机B接收到第四步的数据报，状态置为closed 主机A经过2MSL（超时等待时间）之后，状态置为closed
TCP------>4次挥手中的问题
1.第2步和第3步为什么不能和3次握手流程一样，进行合并
原因：第2步是TCP协议在系统内核中实现时，自动响应的ack 第3步时应用程序手动调用close来关闭连接的 程序在关闭连接之前，可能需要执行释放资源等前置操作，所以不能合并（TCP协议实现时，没有这样进行设计）
2.第3步中，主机A为什么不能直接设置为closed状态
原因：第4个数据报可能丢包，如果直接置为closed，丢包后无法重新发送数据。主机B达到超时时间之后，会重发第三个数据报，然后要求主机A再次回复ack
3.服务器出现大量的close_wait状态，是为什么？
服务端没有正确的关闭连接（程序没有调用close，或者没有正确使用）
(5)滑动窗口（效率）
如果没有滑动窗口，网路数据传输就是串行的方式（发送一次之后，等待应答，这个时间内，主机A无事可做，主机B也一样），效率比较差。
使用滑动窗口可以解决效率的问题：类似于多线程的方式，并发的，同时发送多个数据报。如下图：
1.窗口大小指的是无需等待确认应答而可以继续发送数据的最大值. 上图的窗口大小就是4000个字节(四个段).
2.发送前四个段的时候, 不需要等待任何ACK, 直接发送;
3.收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推;
4.操作系统内核为了维护这个滑动窗口, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答;只有确认应答过的数据, 才能从缓冲区删掉;
5.窗口越大, 则网络的吞吐率就越高;
丢包问题：1.数据报丢包
如上图：如果主机A发送的数据报丢包，主机B的ack应答，会根据主机A已经收到的连续数据报的最大值 1返回ack应答，当主机A收到三个同样的ack应答之后，会将丢掉的数据报进行重发（具有接收缓冲区，来记录已经接收的数据报的序号）
2.ACK应答丢包：这种情况下, 部分ACK丢了并不要紧, 因为可以通过后续的ACK进行确认
如果是滑动窗口的第一个包丢了，根据上述数据报丢包的情况，收到了第6个报的ACK应答，是从6001开始，说明第一个报主机B已经收到，所以ack丢包可以根据后序ack确定数据报主机B是否收到
关于滑动窗口的几个问题：
<1>.滑动窗口的大小：无需等待确认应答而可以继续发送数据的最大值 <2>.如何确定窗口的大小：由拥塞窗口和流量控制窗口决定（滑动窗口大小=（拥塞窗口大小，流量控制大小））（后序会讲到）
<3>.如何滑动：依赖于ACK的确认序号（ack确认序号前的数据报都已经接收到了），在该ACK确认序号前，当次并行收到了多少个数据报，就可以滑动多少
<4.>为什么要有接收缓冲区和发送缓冲区：发送端的发送缓冲区：记录已经发送的数据——搜到对应的ACK应答，才可以清理该数据 接收端的接收缓冲区：记录已经接收的数据——如果发送数据报丢包，才知道让对方重发
(6)流量控制机制（安全机制）
接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继而引起丢包重传等等一系列连锁反应.
接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端; 窗口大小字段越大, 说明网络的吞吐量越高;
接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端; 发送端接受到这个窗口之后, 就会减慢自己的发送速度;
面试官都震惊，你这网络基础可以啊！如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端.
当接收端使用流量控制窗口时，如何保证接受端的数据安全？告诉发送端，影响发送端滑动窗口的大小
(7)拥塞控制机制（安全机制）
少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;
发送端在网络状态不明的情况下，贸然发送大量的数据，会造成网络拥堵，需要先发送少量数据探路，设置拥塞窗口的大小
如上图：如何确定拥塞窗口的大小
此处引入一个概念程为拥塞窗口 发送开始的时候, 定义拥塞窗口大小为1;
每次收到一个ACK应答, 拥塞窗口加1;
每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口;
为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍. 此处引入一个叫做慢启动的阈值
当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长
(8)延迟应答机制(效率)
举个例子：
假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K; 但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;
在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来; 如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;
延迟应答类型：数量限制: 每隔N个包就应答一次; 时间限制: 超过最大延迟时间就应答一次;
(9)捎带机制（效率）
在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 “一发一收” 的，意味着当客户端给服务端发送请求时，服务端会给客户端响应数据，此时ACK就像可以搭请求数据的顺风车，一起发送。
接收端响应的ACK，和主动发送的数据，可以合并返回。
<3>TCP的总结
(1)TCP特性
TCP是有连接的可靠协议
(2)面向字节流
TCP既有发送缓冲区，也有接收缓冲区，数据没有大小限制
调用write时, 数据会先写入发送缓冲区中;
如果发送的字节数太长, 会被拆分成多个TCP的数据包发出; 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区; 然后应用程序可以调用read从接收缓冲区拿数据;
另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工
(3)粘包问题
在TCP的协议头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段 站在传输层角度看
报文是一个一个按照顺序排序好放在缓冲区，但是站在应用层角度看，都是一个个数字，不知道哪个数字是一段保文的开头，也不知道哪一个数字是结尾。这就是粘包 所以得明确一个报文的开头和结尾
但是对应UDP来说：对于UDP, 如果还没有上层交付数据, UDP的报文长度仍然在.
同时, UDP是一个一个把数据交付给应用层.就有很明确的数据边界. 站在应用层的站在应用层的角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收. 不会出现"半个"的情况
<4>UDP VS TCP
(1)UDP和TCP的特性
TCP用于可靠传输的情况, 应用于文件传输, 重要状态更新等场景; UDP用于对高速传输和实时性要求较高的通信领域, 例如, 早期的QQ, 视频传输等. 另外UDP可以用于广播
(2)如何使用UDP进行可靠传输
引入序列号, 保证数据顺序; 引入确认应答, 确保对端收到了数据; 引入超时重传, 如果隔一段时间没有应答, 就重发数据;
4.MTU和IP协议
<1>MTU协议
MTU相当于发快递时对包裹尺寸的限制. 这个限制是不同的数据链路对应的物理层, 产生的限制.
以太网帧中的数据长度规定最小46字节,最大1500字节,ARP数据包的长度不够46字节,要在后面补填充位;最大值1500称为以太网的最大传输单元(MTU),不同的网络类型有不同的MTU;
如果一个数据包从以太网路由到拨号链路上,数据包长度大于拨号链路的MTU了,则需要对数据包进行分片 不同的数据链路层标准的MTU是不同的;
<2>IP协议
1.协议头格式
简单了解：4位版本号(version): 指定IP协议的版本, 对于IPv4来说, 就是4.
8位服务类型(Type Of Service):
3位优先权字段(已经弃用),
4位TOS字段, 和1位保留字段(必须置为0).
4位 TOS分别表示: 最小延时, 最大吞吐量, 最高可靠性, 最小成本.
这四者相互冲突, 只能选择一个. 对于ssh/telnet这样的应用程序, 最小延时比较重要; 对于ftp这样的程序, 最大吞吐量比较重要（应用层协议需要不同安全/效率需求，此时可以设置服务类型来满足）
下面三个字段都与数据链路层MTU相关：
5.HTTP和HTTPS
<1>HTTP
(1)Http的前置知识
1)网络数据传输
网络数据传输，都需要使用相同的协议，双方约定好的统一规范（封装和解析的数据格式规范）
协议：数据格式的约定
目标：对于http协议来说，就是学习里边的协议格式。结合理论实操，进行程序的调试，http协议格式本身，http数据中，包括自己的数据格式
2)认识URL
(2)HTTP
1)域名
域名：基于DNS解析为IP
IP：网络中定位主机的地址（逻辑地址）
PORT：端口号，定位某个主机中唯一的进程（应用程序）
url：url是全路径（绝对路径）
特殊注意事项：输入域名直接访问，其实是访问/这个资源的路径。浏览器中，不输入端口号，是因为http协议的默认端口是80 url中的请求数据：请求路径？key1=value1&key2=value2… 问号前代表绝对路径，问号后代表请求的资源，数据
2)http协议格式
3)http请求方法
重点了解get和post方法
get和post方法的区别：
1.get的请求数据只能放在url中，post的数据，可以放在url和请求体 2.url长度有限制，所有get方法请求数据不能太多，冰球url只能传输ascli字符 3.安全性将，post可以存放请求数据在请求体，相对更加安全 其他区别：了解即可
4)http状态码
服务端返回（服务端设置），站在服务端的角色上，状态码都是对应的含义，站在客户端的角色上就不一定
注：x表示0到9的数字 重点掌握：
5)http头信息
<2>HTTPS
HTTP是明文传输的，不安全 HTTPS是基于HTTP SSL/TSL来实现的，发送的数据需要加密，接收到的数据需要解密，比HTTP安全，但是传输效率比HTTP低
<1>.前置知识：为什么需要HTTPS
如上图：HTTP是不安全的，在传输的过程中，当客户端发送数据时，可能被钓鱼网站“欺骗”，将钓鱼网站当作服务端，或者直接被钓鱼网站窃取到数据，然后更改，造成不安全的影响
此时需要解决：a：如何保证服务器是真实的，不是钓鱼网站？b：解决网络数据传输，使用明文，所有路途中的设备，如果获取到，存在信息泄露
所以，就要使用到证书来解决安全问题 a：权威的证书机构颁发的证书（安装浏览器时，初始化就内置权威证书）（解决上述a问题） b：https服务器证书（解决上述b问题）
私钥，公钥，密钥：
密钥：客户端，服务端用来加解密 对称加密：使用同一个钥匙，来加解密 公钥的生成（SSL握手阶段）：见SLL握手
https中涉及的细节：
1.使用公钥和私钥来生成密钥（这里是非对称加密生成密钥）
2.密钥加解密真正的数据（这里进行的对称加密，效率比非对称加密高）
如何获取并验证服务器证书：
具体流程：
流程 1.用密钥进行加解密：
<1>.客户端向服务端索要并验证公钥
<2>.双放协商生成"对话密钥"
<3>.双方采用“对话密钥”进行加解密通信
2.HTTPS握手阶段（根据公钥私钥生成对话密钥）（以上1，2步需要保证对话密钥不被钓鱼）
<1>.首先客户端给出协议版本号，一个客户端生成的随机数，以及支持的加密方式
<2>.服务端确认双方使用的加密方式，给出数字证书，以及一个服务器生成的随机数
<3>.客户端确认数字证书有效，然后生成一个新的随机数，并使用数字证书中的公钥，加密这个随机数，发个服务端
<4>.服务端使用自己的私钥，获取客户端发来的随机数
<5>.客户端和服务端根据约定的加密方式，使用前面的三个随机数，生成密钥
3.发送数据的阶段：客户端使用对话密钥加解密真正的数据 服务端使用对话密钥加解密真正的数据
注意：此部分被钓鱼也没有关系（对话密钥无法解密）
正向代理和反向代理
<1>.正向代理服务器
<1>概念
正向代理服务器：抓包工具 正向代理是一个位于客户端和目标服务器之间的代理服务器(中间服务器)。为了从原始服务器取得内容，客户端向代理服务器发送一个请求，并且指定目标服务器，之后代理向目标服务器转交并且将获得的内容返回给客户端。正向代理的情况下客户端必须要进行一些特别的设置才能使用。
<2>原理图
<3>使用场景和特点
1.特点：要访问的服务器只知道代理服务器来访问它，并不知道真实的客户端是谁 2.使用场景：正向代理的典型用途是为在防火墙内的局域网客户端提供访问Internet的途径。正向代理还可以使用缓冲特性减少网络使用率。
<2>.反向代理服务器
<1>概念
反向代理服务器：nginx等 反向代理正好相反。对于客户端来说，反向代理就好像目标服务器。并且客户端不需要进行任何设置。客户端向反向代理发送请求，接着反向代理判断请求走向何处，并将请求转交给客户端，使得这些内容就好似他自己一样，一次客户端并不会感知到反向代理后面的服务，也因此不需要客户端做任何设置，只需要把反向代理服务器当成真正的服务器就好了
<2>原理图
<3>使用场景和特点
1.特点:反向代理服务器隐藏了真实服务器的信息，例如淘宝，京东，天猫等
2.使用场景: 反向代理的典型用途是将防火墙后面的服务器提供给Internet用户访问。
反向代理还可以为后端的多台服务器提供负载平衡，或为后端较慢的服务器提供缓冲服务。
