网络协议Tcp/Ip

   图1

图2

图3

 自己的理解，仅供参考，不对希望指正：

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口
域名通过dns与ip地址对应，而ip地址通过arp协议来对应到mac地址

服务启动
1、去注册域名绑定ip端口

当一条数据通过https发送时候
1、通过dns解析目标ip和端口
2、传输层打包源目端口、网络层打包源目ip(图2、图3)
3、打包以太网包（Mac地址-数据链路层）
4、到接收端 解析以太网找到目的ip(mac上绑定ip)，发送到对应的ip机器上，
5、ip再次解析找到端口，发送到制定的应用上

如果是大数据发送会在 网络层(ip)进行拆包，每次发送包的时候有超时重传(rto) 应答确认，来判断数据是否发送失败，同时RTT往返时延等，来确定rto的超时时间

​​​​​​​

注意：步骤7是开始一层一层的拆包，skb=sk_buffer

 TCP的基本特性
Ø 面向连接(3次握手、4次挥手)
Ø 可靠性(数据的完整传输)
Ø RTT和RTO（大数据传输确保）
Ø 数据排序 （分包会对数据打标签1、2... 服务器接受后排序组装，数据发送会经过多个省，谁先到达不确定）
Ø 流量控制（客服端发送数据的时候，服务器 告诉 客户端 下一次发送多少数据量）
Ø 全双工（客服端 同时发送http2.0、半双工 keep-alive发送后同时完成接收，才能进行下次数据发送http1.1、单工 发送后马上断开htpp1.0、http3 可能要改成udt）如下图

TCP介绍(syn请求连接 ack确认 fin请求断开)

第一次握手：客户端请求建立连接。
第二次握手：服务端应答客户端， 并请求建立连接。
第三次握手：客户端针对服务端请求确认应答。 

为什么需要3次握手?
TCP是面对连接的， 所以需要双方都确认连接的建立。

第一次握手：服务器 知道客服端 发送没问题
第二次握手：客户端 知道服务器 接收没问题
                       客户端 知道服务器 发送没问题
第三次握手：服务器 知道客户端 接受没问题 

 3次握手的漏洞-SYN洪泛攻击

攻击者利用伪造的IP向服务端发出请求(第一次握手)， 而服务端的响应(第二次握手)的报文将永远发送不到真实的客户端， 服务端在等待客户端的第三次握手(永远都不会有的)， 服务端在等待这种半开的连接过程中消耗了资源， 如果有成千上万的这种连接， 主机资源将被耗尽， 从而达到攻击的目的。

解决方案
1、无效连接监控释放
2、延缓TCB分配方法
3、防火墙(主要)

四次挥手

第一次挥手： 客户端发送关闭请求(c不在发送数据给s)
第二次挥手： 服务端响应客户端关闭请求(s可能还有数据要发送给c)
第三次挥手： 服务端发送关闭请求（s告诉c,数据发送完成。c进入time_waiting状态）
第四次挥手： 客户端发送关闭确认请求 (c告诉s你可以关闭连接，我过一会关闭)
注意：2、3有可能会合并

1、为什么需要四次挥手
TCP是双全工(即客户端和服务器端可以相互发送和接收请求)， 所以需要双方都确认关闭连接。
2、为什么需要TIME-WAIT状态？
2.1第四次挥手丢失需要重发（超过一定的时间第三次挥手会再次执行）
2.2a/b服务 同时拥有8080端口，当第三次挥手执行完毕(a进入time-wait)，a被关闭了，b启动了。这时候新的化身可能受到属于原来连接携带应用程序数据的TCP报文段，这显然是不该发生的。所以a属于time_wating状态 b端口不运行被启动
MSL 最长报文段寿命(存活最长时间REC 2分钟 30秒)time_wating 1~4分钟

一次完整http请求的过程

1、 首先进行DNS域名解析（ 本地浏览器缓存、 操作系统缓存或者DNS服务器）
2、 三次握手建立 TCP 连接
3、 客户端发起HTTP请求
4、 服务器响应HTTP请求，
5、 客户端解析html代码， 并请求html代码中的资源
6、 客户端渲染展示内容
7、 关闭 TCP 连接

DNS劫持和HTTP劫持

dns劫持：dns解析ip的时候ip被修改
http劫持：请求回来的时候，加入其他js、html代码
路由器被黑了、不要使用运营商的dns 自己设置一个好的dns、直接重定向、http改https

常用的网络抓包工具Wireshark和stetho

1、捕获过滤起(BPF语法 Npcap)

最后一行表示第13个字节第4位 为4的过滤

2、显示过滤器

​​​​​​​​​​​​​​