TCP三次握手四次挥手及S7

TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)协议属于传输层协议。

  • TCP(Transimision Control Protocal)
  • 传输控制协议
  • 可靠的、面向连接的协议
  • 传输效率低S
  • UDP(User Datagram Protocal)
  • 用户数据报协议
  • 不可靠的、无连接的服务
  • 传输效率高

网络模型

OSI 功能 TCP/IP
7应用层 文件传输,电子邮件,文件服务,虚拟终端 TFTP,HTTP,SNMP,S7, Modbus, FTP,SMTP,DNS,Telnet 等等
6表示层 数据格式化,代码转换,数据加密 没有协议
5会话层 解除或建立与别的接点的联系 没有协议
4传输层 提供端对端的接口 TCP,UDP
3网络层 为数据包选择路由 IP,ICMP,OSPF,EIGRP,IGMP
2数据链路层 传输有地址的帧以及错误检测功能 SLIP,CSLIP,PPP,MTU
1物理层 以二进制数据形式在物理媒体上传输数据 ISO2110,IEEE802,IEEE802.2
  • 针对OSI网络参考模型,通常我们TCP/IP就直接可以理解成
TCP/IP 说明
应用层 例如什么S7通讯协议啊,FTP协议,Modbus通讯等等均是应用层的一种协议,其实还是基于TCP传输层
TCP层也称传输层 发包
网络层(IP) 网络互通嘛,没什么好解释的
网络接口层 例如什么以太网啊,RS232/485的一些串口啊

以上是一些基础的协议,下面找一个TCP的报头的图片


yyun.jpg

解释:源端口号和目标端口号各占16个位
顺序号有的叫序列号:占32位
确认号:
占32位
头部长度6位,保留6位

  • URG:报文段紧急。

  • ACK:确认序号有效。

  • PSH:接收方应该尽快将这个报文段交给应用层。

  • RST:重建连接。

  • SYN:发起一个连接。在握手完成后SYN为1,表示TCP建立已连接。此后的所有报文段中,- SYN都被置0。

  • FIN:释放一个连接。如果源主机数据发送完毕,将把该连接下要发送的最后一个报文段的报- 头中的FIN位置1,或将该报文段后面发送的报头中该位置1。
    窗口6位
    校验和16位,紧急指针16位
    可选项8的倍数 位
    数据

  • 由此不难看出TCP至少是20个字节

那么具体是怎么三次握手的呢,先找一张图片,自己就不画了,网上一搜一大堆

TCp握手.jpg
  • 解释
  • 客户端向服务端发起请求SYN,和顺序号seq状态改为SYN_SEND
  • 服务端收到后,确认收到ACK信号即客户端序列号+1,发送SYN请求,服务端顺序号发给服务端,同时状态更改为SYN_RECV
  • 客户端收到后返回服务端确认信号即ACK即服务端序列号+1,另外将置后的顺序号发给服务端,状态进入Established

四次挥手

TCP四次挥手.png

就是将服务端给哭护短发送请求时拆分为了两次,大家可以网上找更详细的图片解析

  • 客户端向服务端发送 FIN (完成信号)信号+ ACK(确认信号) 报文,序号为 X。 客户端进入 FIN-WAIT1第一次等待

  • 服务器端回复 ACK 报文。附带序号Z和确认序号X+1,表示服务器已经接受到了客服端的报文。但是由于服务器可能还在处理事务,因此,报文并不会携带FIN标志。状态:CLOSE WAIT(服务端处理事件等待)

  • 在一段时间之后,服务器已经处理完毕,发送带有 FIN和ACK的报文,序号为Y,图中未标出确认序号为 X + 1 。 状态: ACK-LAST

  • 客户端发送ACK报文,序号为 X+1,确认号Y+1 。 客户端进入: TIME_WAIT。服务端进图CLOSE(初始状态)

提一嘴S7通讯,可以自己抓包,很清晰的看到三四握手发的包内容以及S7的协议结构

  • 至于与PLC的通讯其实都更改应用层的协议,传输过程都时一层报文一层报文的累加最后成了一个固定的协议,例如西门子S7协议,是按照OSI模型的形式拼接的报文

  • S7+CTP+YPKT+TCP/IP(具体可以去抓包,可以一目了然)

[太晚了...先这样,明天早起上班,回头再补充]

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,080评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,422评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,630评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,554评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,662评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,856评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,014评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,752评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,212评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,541评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,687评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,347评论 4 331
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,973评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,777评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,006评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,406评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,576评论 2 349

推荐阅读更多精彩内容