TCP IP参考模型-三次握手-四次挥手

 

 1,了解TCP/ IP参考模型

 2,了解TCP/IP基本概念

TCP IP模型 提出的时间早于OSI  DOD美国国防部提出的

 

DOD  数据链路层和物理层--》网络接入层 

 

 

 

TCP/IP 协议栈

 

 

 

 

 

 

 

 

 

 

 

 

 

 

每个信封写相应的内容

底层以报文的形式传递  101010

数据帧由各各字段组成         字段由固定格式  有标准化文件定义的    还原成人类能读懂的形态 报文的形态分析 

 

 

 

Data 就是 应用层的pyload

 

 

 

圆圈标注的就是TCP的头部

Sequence number(32)  确保数据发送的序列号

Acknowledgement number(32)  回复  

Window(16) 窗口的大小

Checksum(16)校验和

Control bits(6)控制位  6个bits 每一位都有特俗的用途 置1

 

 

 

源端口号 

目的端口号 超市有卖食品的  有卖药品的 有卖生活用品的  分不同的店门牌号(1-65535)

1-1024  作为保留的端口号  HTTP 80端口

1024 可以作为自定义的 进程可以定义2000  服务开启之后就点会监听2000 有数据上来就会送到这个端口

 网的时候写的一般是域名,域名服务 PC底层不知道这个东西,解析成IP DNS

 

 

 

 

源端口 目的端口 长度 校验和载荷

 

 

 

面向连接的过程 开始传输之前都得需要建立一个TCP的会话,基于这个会话传输数据

会话的建立过程A和B建立会话  A客户端 B服务端  A发起会话

重点关注三个字段 seq(自己发出的序列号)  ack(1,确认号 确认对端的(序号哈)2,我请求你序号为1的下一个序号)  ctl(控制位 SYN(同部位 要建立TCP握手),ACK)

 

 

 

 A决定要和B拆伙了 A要断开TCP连接 由A发起TCP的消息 这个TCP的消息控制位有两个位是置位的;B收到这个消息之后 A要和我拆伙先回复一个CTL=ACK确认分组的  在回复一个ctl=ACK,FIN置位的 告诉A 确认要和你拆了 最后 A回复 ACK宣告TCP的拆除

序列号是自己的  确认号的是对端的

 

 

 

 接收方的缓冲区 建立tcp三次握手之后 A知道B的承受范围是3  意味着A最多可以发三个数据 而不需要你做确认 不需要我发一个你确认一个, A知道你的承受能力是3所以我一次性给你发三个 然后我在等你的确认,关注B的窗口大小,A回复的win=3是A的窗口大小不需要关心,瞬间把B的窗口大小沾满,有一个数据被CPU拿走了处理了,B要做A(seq=103)做确认,发一个TCP的消息给A 回复ack=104 确认103的数据同时请求A下一条数据win=1; 窗口值一次说话的次数

 

 

 举例:甲和乙  甲说一句  乙回复一句而且说的每一句话都需要对上一句做出确认;这样的聊天效率太低了 怎么解决这个问题呢

乙呢性情阴晴不定 这个时刻不忙一次性可以听4句话,下一个时刻比较忙一次性只能听一句话,这时候呢甲发数据能不能灵活一点,我一次性发三个数据出去,乙对这三个数据进行确认,下一时刻乙比较忙乙能不能通知甲不要一次性说三句话了我听不到, 你说一句话吧,甲就说一句话。下一时刻乙又闲了可以听六句话了,通知甲我可以听六句话了,甲下次就发6句话

 

 

 

数据分组的格式 每一个时刻网线光纤上都有数据传输  数据有固定的格式 就是用IP定义的 IP协议 因特网层重点的IP协议

ICMP  PING  这几个都是网络层协议

IGMP

RARP RARP是寻找与物理地址对应的IP地址

ARP  寻找MAC地址

 

 

 

 

 Data就是四层+上层的数据; 第四层基于需要头部添加TCP还是UDP如果都不需要就没有第四层头部,上边是IP的头部

Version 版本,header length(4)头部长度 priority &Type of service(qos的)

Total 报文的总长度 identification和fragment offset 做分片的  flags(一些特殊置位标志)

Time to live  ttl值仿环的 写入一个值 64 转发的时候  减1 当一个报文TTL=0 数据包就会丢弃

Protocol 类似信封上边写 内有文件一份 告诉IP接收方 data 这里头是什么样的报文 (tcp ,udp)

Header checksum : 校验和校验数据是否损坏

源IP 目地IP

 

 

 

当pc1 和 pc2 通讯要知道 PC2的 IP和 mac  第三层IP 第二层目的MAC,PC1 吼一下(广播)PC2一看是我自己 单播回去给PC1,P3 P4 P5一看不是我的扔掉,PC1就知道PC2的MAC地址 ,PC1就会把PC2的ip和MAC地址形成一个表项存放在自己的表格当中,这个表格就是ARP表 用来帮PC1拿到PC2的MAC地址的协议,就叫做ARP地址解析协议

 

 

 

 

目的MAC是FFFF就是 广播地址

目标MAC 0.0.0.0   PC2收到ARP消息的时候 回送ARP消息  PC2 IP和mac形成对应

 

 

 

 

 

 Arp是完全不需要确认的所以你根本不知道,发送arp消息给我的哥们究竟是谁我是不需要确认的 、那这样就会出现问题

发送的IP的路由的IP(1.254) 发送的MAC是自己的MAC地址这样就可以监听PC1的数据,做的在隐蔽一点接收到的数据在转发出去可以上网,这样就可以源源不断的监听PC1的数据了

 

 

 

 

 

 

 

 

 

 

电脑上 查看arp 消息  arp -a

 

 Traceroute  / tracert 从我本地到目的之间所穿越哪一台路由器的IP地址 这样可以帮助我分析数据行走的路径

 

 

 

 PC 网关是路由器的IP; 表格中是每个节点的IP和MAC;当PC要访问server web 发生了什么事情 假设tcp的三次握手建立起来了

 

 

整个过程可以通过这样的模型

 

PC应用层下来的数据 被每一层次加上信封,被路由器还原成帧,查看帧头,到网络层查看目的IP,路由--》最终到达Server应用层。这是一个宏观的分析

 

 

 

 PC构造了一个数据帧是HTTP这个进程构成的数据,这是数据是最终要传到Server,数据转到传输层;HTTP是基于TCP的开发的应用所以到传输层就要TCP的头部。TCP的头部就需要加源端口号,目的端口号,源端口号是随机产生的;目的端口号就是对端服务器监听的端口号;缺省的端口号80,当然有的服务器自定义了端口号,再往下就是因特网层 源PC -》IP地址,目的地址是server地址,协议号6 表示IP的后边躲着一个TCP头部,再往下就是数据链路层,先到R1在到R2再到server, 要正确的到达R1,要给数据写上以太网帧头,帧头当中就要写地址了,对以太网来说就要写MAC地址了,mac地址只有以太网才有的地址,源MAC就是PC的mac地址,目的mac就是pc网关对应的mac地址,初始没有MAC要发送arp广播拿到mac再去写,类型字段0x0800 意思我后边躲着什么是(以太网层IPV4的报文)变成二进制发出去

 

 

 

 R1收到数据以后,先把他还原成帧,然后查看帧头,帧头上写的目的MAC地址正好是自己的MAC的地址,从类型判断出后边是一个IPV4的数据,所以把帧头拆到,把后边的数据交给IPV4协议栈去处理,IPV4协议栈处理到这个数据的时候,查看IP头发现目的IP地址不是自己任何接口的IP地址,证明这个数据包不是给自己的,那么怎么办呢,就会拿着这个目的地址去地图里边(路由表)中去查找,那么这个路由器拥有整个网络每个角落的路由路径,找到这个路径之后,发现这个数据包是需要从这个接口G0/0/1扔出去,扔给R2的的0/0/0接口,会把这个数据再加一个新的帧头,

 

 

 

 

 这个时候MAC地址是G0/0/1的MAC地址,目的MAC是R2的MAC地址,然后把这个数据帧发给R2,R2数据帧收到数据后看帧头,发现目的MAC地址 就是自己,拆掉数据帧给IP,

 

 

 

 IP协议栈 发现目的IP不是自己但是本地的直连的网段,这时候在写上帧头目的MAC server的MAC,把这个数据帧发送给server,server收到数据帧发现目的MAC就是自己的MAC,把帧头拆掉,拆掉之后交给IP协议栈处理,ip协议栈发现目的IP地址就是自己的ip地址,于是乎他把IP头拆掉通过协议号6知道后边是一个TCP的头部,于是乎把后边的TCP的协议栈处理,tcp协议栈发现这个目的端口号是80端口,于是乎他又看一下本地TCP 80端口开没开,发现本地的端口开了,而且对应的是HTTP进程在监听这时候就会把TCP头部拆掉,把数据交给HTTP进程去处理

 

posted @ 2020-08-14 13:51  鬼蠍  阅读(414)  评论(0编辑  收藏  举报