计网2——TCP/IP协议

TCP/IP 协议是协议簇包含多个层的协议。
应用层： HTTP/IP
传输层：TCP/UDP
网络IP 层： ARP/RARP， IMCP，IP
数据链路层

TCP/IP 的工作流程：
数据链路层从ARP 中获得数据传输的信息（IP——目的MAC）再从IP中得到具体的数据信息。

IP 协议（不可靠/无连接服务）：
IP ：可以提供多个物理网络的虚拟网络，并且提供无连接的数据交付（直接交付（同网络，不经过路由器传输）/间接交付（通过路由器转发到目的网络涉及到IP数据报的路由选择问题））
不可靠：1.不保证IP 数据可以到达目的地
2.发生某种错误，（例如路由缓冲区满），直接丢弃数据报，发送ICMP 消息给信源端
无连接：不按顺序发送；每个数据报的路由选择可能不同，线路不同
间接交付依靠多个路由器协同工作，将数据由一个路由转发到另一个路由，直至实现跨网络，找到目的网络号。
IP 选路算法利用了每台主机的路由表（只有IP 中的网络号；N，R向量 N 为目的IP地址，R为途径的下一个路由器IP 地址），该表中记录了目的站，以及到达目的站的信息（类似与送快递，路由相当于多个中转站）
其中，数据经络路由时要做分组投递处理（属于哪个区域，投递到哪个区域的路由），则路由器工作实现两个阶段：
1）如何到达目标网络
2）分组到达目标网络后，由终端路由器分组送到目标主机。
路由表：
1.destiny :目的IP
2.next hop router:下一个路由的IP地址/直连IP地址
3.标志：路由/直连端口
4.网络接口（网卡）
转发数据过程/搜索过程：
搜索路由表，查看能够与目的IP 匹配的表目
优先级：同网络主机地址匹配> 同子网的路由器 > 同网号的路由器 > 默认路由 无法找到 丢弃包
以上过程，同步修改IP报文中的TTL字段（IP允许tong通过的最大网段数量（经过的路由器数量） 8位），即每一次路由，TTL-1 ，当TTL =0抛弃
路由器接收到数据报，送交到数据链路层中利用ARP将IP-MAC，根据MAC 查找下一跳路由器

ICMP 网络控制协议
在IP主机和路由器之间控制消息的传递（网络痛不痛，主机是否可达，路由是否可用等网络本身的消息），不用于直接传输用户数据。
ICMP功能：差错通知和信息查询
1.通知发送过程中IP 丢包的原因
2.确认IP 包是否成功到达
ICMP 报文包含在IP数据报中，ICMP 本身也是作为IP数据用于搬运的，在IP 的首部中协议字段为1，说明该报文是ICMP 报文
5）类型；6）代码；7）选项数据；这三个包含在ICMP数据部分的字段。其中，5，6 是ICMP 用来错误通知和信息询问的组合组形式

ICMP实现：
MTU(计算机一次能够送出去的数据最大长度)探索——探索可以通过的MTU
改变路由
源点抑制（减缓送行方的发送速度，防止缓存溢出）
Ping 命令：IP 层次上调查与指定机器是否来联通，调查数据报往复所需的时间
1.IP 层次上调查与指定机器是否来联通（网络通不通）
2.统计TTL和响应时间
ping命令无法判断是否来联通的三个原因：
1.目标服务器不存在
2.数据包交流时间超时
3.目标服务器无回答
traceroute:打印可执行程序主机，一直到目标主机经历的路由器数量

TCP/IP 的三次握手协议，四次分手
TCP首部（20字节固定）：首部含有序号（seq）和确认号(ACK),以及标志位（ACK,RST,SYN,FIN）
三次握手：（SYN攻击） #netstat -nap | grep SYN_RECV
SYN攻击：
时机：服务器已发送ACK+SYN ，客户端还回复ACK的半连接态
行为：客户端在该时间内大量伪造假IP，并不断向服务器发送SYN，服务器回回复确认包，并等待回复，由于假IP无法得到回复，则服务器启动重发机制至超时。伪造SYN 占用了未连接队列，其他SYN 将因队列满而丢弃，因此网络堵塞，乃至系统瘫痪 DDOS攻击
三次握手建立连接时，发送方再次发送确认的必要性？
主 要是为了防止已失效的连接请求报文段突然又传到了B,因而产生错误。假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结 点长时间滞留了，一直延迟到连接释放以后的某个时间才到达B，本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出一次 新的连接请求，于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了，这样一直等待A发来数据，B的许多 资源就这样白白浪费了。
四次挥手释放连接时，等待2MSL的意义？
第 一，为了保证A发送的最有一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN和ACK 报文段的确认。B会超时重传这个FIN和ACK报文段，而A就能在2MSL时间内收到这个重传的ACK+FIN报文段。接着A重传一次确认。
第二，就是防止上面提到的已失效的连接请求报文段出现在本连接中，A在发送完最有一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。

常见的应用中有哪些是应用TCP协议的，哪些又是应用UDP协议的，为什么它们被如此设计？
以下应用一般或必须用udp实现？
多播的信息一定要用udp实现，因为tcp只支持一对一通信。
如果一个应用场景中大多是简短的信息，适合用udp实现，因为udp是基于报文段的，它直接对上层应用的数据封装成报文段，然后丢在网络中，如果信息量太大，会在链路层中被分片，影响传输效率。
如果一个应用场景重性能甚于重完整性和安全性，那么适合于udp，比如多媒体应用，缺一两帧不影响用户体验，但是需要流媒体到达的速度快，因此比较适合用udp
如果要求快速响应，那么udp听起来比较合适
如果又要利用udp的快速响应优点，又想可靠传输，那么只能考上层应用自己制定规则了。
常见的使用udp的例子：ICQ,QQ的聊天模块。
以qq为例的一个说明（转载自知乎）
**登陆采用TCP协议和HTTP协议，你和好友之间发送消息，主要采用UDP协议，内网传文件采用了P2P技术。**总来的说：
1.登陆过程，客户端client 采用TCP协议向服务器server发送信息，HTTP协议下载信息。登陆之后，会有一个TCP连接来保持在线状态。
2.和好友发消息，客户端client采用UDP协议，但是需要通过服务器转发。腾讯为了确保传输消息的可靠，采用上层协议来保证可靠传输。如果消息发送失败，客户端会提示消息发送失败，并可重新发送。
3.如果是在内网里面的两个客户端传文件，QQ采用的是P2P技术，不需要服务器中转。
https://blog.csdn.net/qq_41517936/article/details/80886618?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-6.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-6.nonecase