计网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

©️2020 CSDN 皮肤主题: 数字20 设计师:CSDN官方博客 返回首页