简述tcp协议的工作过程

简述tcp协议的工作过程,第1张

TCP/IP协议(又名:网络通讯协议)即传输控制协议/互联网协议,是一个网络通信模型,以及一整个网络传输协议家族。这一模型是Internet最基本的协议,也是Internet国际互联网络的基础,由网络层的IP协议和传输层的TCP协议组成。 其定义了电子设备如何连入因特网,以及数据如何在它们之间传输的标准。TCP负责发现传输的问题,而IP是给因特网的每一台联网设备规定一个地址。

为了减少网络设计的复杂性,大多数网络都采用分层结构。对于不同的网络,层的数量、名字、内容和功能都不尽相同。在相同的网络中,一台机器上的第N层与另一台机器上的第N层可利用第N层协议进行通信,协议基本上是双方关于如何进行通信所达成的一致。

不同机器中包含的对应层的实体叫做对等进程。在对等进程利用协议进行通信时,实际上并不是直接将数据从一台机器的第N层传送到另一台机器的第N层,而是每一层都把数据连同该层的控制信息打包交给它的下一层,它的下一层把这些内容看做数据,再加上它这一层的控制信息一起交给更下一层,依此类推,直到最下层。最下层是物理介质,它进行实际的通信。相邻层之间有接口,接口定义下层向上层提供的原语 *** 作和服务。相邻层之间要交换信息,对等接口必须有一致同意的规则。层和协议的集合被称为网络体系结构。

每一层中的活动元州核族素通常称为实体,实体既可以是软件实体,也可以是硬件实体。第N层实体实现的服务被第N+1层所使用。在这种情况下,第N层称为服务提供者,第N+1层称为服务用户。

服务是在服务接入点提供给上层使用的。服务可分为面向连接的服务和面向无连接的服务,它在形式上是由一组原语来描述的。这些原语可供访问该服务的用户及其他实体使用。

TCP是面向连接的通信协议,通过三次握手建立连接,通讯完成时要拆除连接,由于TCP是面向连接的所以只能用于端到端的通讯。

TCP提供的是一种可靠的数据流服务,采用“带重传的肯定册弊确认”技术来实现传输的可靠性。TCP还采用一种称为“滑动窗口”的方式进行流量控制,所谓窗口实际表示接收能力,用以限制发送方的发送速度。

如果IP数据包中有已经封好的TCP数据包,那么IP将把它们向‘上’传送到TCP层。TCP将包排序并进行错误检查,同时实现虚电路间的连接。TCP数据包中包括序号和确认,所以未按照顺序收到的包可以被排序,而损坏的包可以被重传。

TCP将它的信息送到更高层的应用程序,例如Telnet的服务程序和客户程序。应用程序轮流将信息送回TCP层,TCP层便将它们向下传送到IP层,设备驱动程序和物理介质,最后到接收方。

面向连接的服务(例如 Telnet、 FTP、 rlogin、 X Windows和 SMTP)需要高度氏销的可靠性,所以它们使用了TCP。DNS在某些情况下使用TCP(发送和接收 域名数据库),但使用UDP传送有关单个主机的信息。

这是我网络中找的参考,希望对你有帮助。

在多线程任务中,TCP任务通过三次握手能建立可靠的连接,但是经常会发生在数据传输或通信时发生网络突然断开或者长时间连接空循环监听而未进行 *** 作,需要在软件设计时考虑程序运行中检测到服务器对客户端的这一“虚连接”现象。

如果主机崩溃,write是否阻塞取决于内核的tcp缓冲区,但read将一直阻塞,直到超时ETIMEOUT,或由于某些中间路由器的原因返回EHOSTUNREACH/ENETUNREACH。select不能检测到该情况。

如果主机崩溃并重起,客户的write到达主机时主机响应RST,客户的read将返ECONNRESET。

此处的”非正常断开”指TCP连接不是以优雅的方式断开,如网线故障等困知物理链路汪搭消的原因,还有突然主机断电等原因

心跳机制

有两种方法枝汪可以检测:1.TCP连接双方定时发握手消息

2.利用TCP协议栈中的KeepAlive探测

第二种方法简单可靠,只需对TCP连接两个Socket设定KeepAlive探测,所以本文只讲第二种方法在Linux,Window2000下的实现(在其它的平台上没有作进一步的测试)

1)Windows平台

C代码

//定义结构及宏

struct TCP_KEEPALIVE {

u_longonoff

u_longkeepalivetime

u_longkeepaliveinterval

}

#define SIO_KEEPALIVE_VALS _WSAIOW(IOC_VENDOR,4)

//KeepAlive实现

TCP_KEEPALIVE inKeepAlive = {0}//输入参数

unsigned long ulInLen = sizeof(TCP_KEEPALIVE)

TCP_KEEPALIVE outKeepAlive = {0}//输出参数

unsigned long ulOutLen = sizeof(TCP_KEEPALIVE)

unsigned long ulBytesReturn = 0

//设置socket的keep alive为5秒,并且发送次数为3次

inKeepAlive.onoff = 1

inKeepAlive.keepaliveinterval = 5000//两次KeepAlive探测间的时间间隔

inKeepAlive.keepalivetime = 5000//开始首次KeepAlive探测前的TCP空闭时间

if (WSAIoctl((unsigned int)s, SIO_KEEPALIVE_VALS,

(LPVOID)&inKeepAlive, ulInLen,

(LPVOID)&outKeepAlive, ulOutLen,

&ulBytesReturn, NULL, NULL) == SOCKET_ERROR)

{

ACE_DEBUG ((LM_INFO,

ACE_TEXT ("(%P|%t) \WSAIoctl failed. error code(%d)!\n"), WSAGetLastError()))

}

//定义结构及宏 struct TCP_KEEPALIVE { u_longonoffu_longkeepalivetimeu_longkeepaliveinterval} #define SIO_KEEPALIVE_VALS _WSAIOW(IOC_VENDOR,4) //KeepAlive实现 TCP_KEEPALIVE inKeepAlive = {0}//输入参数 unsigned long ulInLen = sizeof(TCP_KEEPALIVE)TCP_KEEPALIVE outKeepAlive = {0}//输出参数 unsigned long ulOutLen = sizeof(TCP_KEEPALIVE)unsigned long ulBytesReturn = 0//设置socket的keep alive为5秒,并且发送次数为3次 inKeepAlive.onoff = 1inKeepAlive.keepaliveinterval = 5000//两次KeepAlive探测间的时间间隔 inKeepAlive.keepalivetime = 5000//开始首次KeepAlive探测前的TCP空闭时间 if (WSAIoctl((unsigned int)s, SIO_KEEPALIVE_VALS, (LPVOID)&inKeepAlive, ulInLen, (LPVOID)&outKeepAlive, ulOutLen, &ulBytesReturn, NULL, NULL) == SOCKET_ERROR) { ACE_DEBUG ((LM_INFO, ACE_TEXT ("(%P|%t) \WSAIoctl failed. error code(%d)!\n"), WSAGetLastError()))}

2)Linux平台

C代码

#include

……

////KeepAlive实现

//下面代码要求有ACE,如果没有包含ACE,则请把用到的ACE函数改成linux相应的接口

int keepAlive = 1//设定KeepAlive

int keepIdle = 5//开始首次KeepAlive探测前的TCP空闭时间

int keepInterval = 5//两次KeepAlive探测间的时间间隔

int keepCount = 3//判定断开前的KeepAlive探测次数

if(setsockopt(s,SOL_SOCKET,SO_KEEPALIVE,(void*)&keepAlive,sizeof(keepAlive)) == -1)

{

ACE_DEBUG ((LM_INFO,

ACE_TEXT ("(%P|%t) setsockopt SO_KEEPALIVE error!\n")))

}

if(setsockopt(s,SOL_TCP,TCP_KEEPIDLE,(void *)&keepIdle,sizeof(keepIdle)) == -1)

{

ACE_DEBUG ((LM_INFO,

ACE_TEXT ("(%P|%t) setsockopt TCP_KEEPIDLE error!\n")))

}

if(setsockopt(s,SOL_TCP,TCP_KEEPINTVL,(void *)&keepInterval,sizeof(keepInterval)) == -1)

{

ACE_DEBUG ((LM_INFO,

ACE_TEXT ("(%P|%t) setsockopt TCP_KEEPINTVL error!\n")))

}

if(setsockopt(s,SOL_TCP,TCP_KEEPCNT,(void *)&keepCount,sizeof(keepCount)) == -1)

{

ACE_DEBUG ((LM_INFO,

ACE_TEXT ("(%P|%t)setsockopt TCP_KEEPCNT error!\n")))

}

心跳机制:定时发送一个自定义的结构体(心跳包),让对方知道自己还活着,以确保连接的有效性。

网络中的接收和发送数据都是使用WINDOWS中的SOCKET进行实现。但是如果此套接字已经断开,那发送数据和接收数据的时候就一定会有问题。可是如何判断这个套接字是否还可以使用呢?这个就需要在系统中创建心跳机制。其实TCP中已经为我们实现了一个叫做心跳的机制。如果你设置了心跳,那TCP就会在一定的时间(比如你设置的是3秒钟)内发送你设置的次数的心跳(比如说2次),并且此信息不会影响你自己定义的协议。所谓“心跳”就是定时发送一个自定义的结构体(心跳包或心跳帧),让对方知道自己“在线”。以确保链接的有效性。

所谓的心跳包就是客户端定时发送简单的信息给服务器端告诉它我还在而已。代码就是每隔几分钟发送一个固定信息给服务端,服务端收到后回复一个固定信息如果服务端几分钟内没有收到客户端信息则视客户端断开。比如有些通信软件长时间不使用,要想知道它的状态是在线还是离线就需要心跳包,定时发包收包。发包方:可以是客户也可以是服务端,看哪边实现方便合理。一般是客户端。服务器也可以定时轮询发心跳下去。心跳包之所以叫心跳包是因为:它像心跳一样每隔固定时间发一次,以此来告诉服务器,这个客户端还活着。事实上这是为了保持长连接,至于这个包的内容,是没有什么特别规定的,不过一般都是很小的包,或者只包含包头的一个空包。在TCP的机制里面,本身是存在有心跳包的机制的,也就是TCP的选项。系统默认是设置的是2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那么好处理。一般,如果只是用于保活还是可以的。心跳包一般来说都是在逻辑层发送空的包来实现的。下一个定时器,在一定时间间隔下发送一个空包给客户端,然后客户端反馈一个同样的空包回来,服务器如果在一定时间内收不到客户端发送过来的反馈包,那就只有认定说掉线了。只需要send或者recv一下,如果结果为零,则为掉线。但是,在长连接下,有可能很长一段时间都没有数据往来。理论上说,这个连接是一直保持连接的,但是实际情况中,如果中间节点出现什么故障是难以知道的。更要命的是,有的节点(防火墙)会自动把一定时间之内没有数据交互的连接给断掉。在这个时候,就需要我们的心跳包了,用于维持长连接,保活。在获知了断线之后,服务器逻辑可能需要做一些事情,比如断线后的数据清理呀,重新连接呀当然,这个自然是要由逻辑层根据需求去做了。总的来说,心跳包主要也就是用于长连接的保活和断线处理。一般的应用下,判定时间在30-40秒比较不错。如果实在要求高,那就在6-9秒。

TCP连接异常断开后 *** 作系统会告诉你,你查询套接字的状态会得到异常,或者当发现函数失败WSAGetLastError的时候也会得到内核的通知。

// 发送回应消息

int nSend = Send4IntMsg(sock, (char*)(LPCTSTR)strSendBuf,

strSendBuf.GetLength(), errMsg)

if (nSend <0) //

发送消息失败

closesocket(sock)//重新连接

在B/S编程和UDP编程时才用到心跳。比如定期向web服务器发一个request证明自己在线。http协议是请求一下就断开了,每次都要重新连接,重新请求,这种情况下才有必要用心跳机制。一般的TCP通信都是长连接,不可能频繁连接和断开。对于长期保持连接的情况,一旦断开, *** 作系统底层都会通知你,你需要解决的是如何获取到系统的通知。

你大概说的是3步握手吧,这跟传真机的5部握手很类似。

下面的资料希望对你有用

TCP/IP 是很多的不同的协议组成,实际上是一个协议组,TCP 用户数据报表协议(也

称作TCP 传输控制协议,Transport Control Protocol。可靠的主机到主机层协议。这里要先

强调一下,传输控制协议是OSI 网络的第四层的叫法,TCP 传输控制协议是TCP/IP 传输的

6 个基本协议的一种。两个TCP 意思非相同。)。TCP 是一种可靠的面向连接的传送服务。

它在传送数据时是分段进行的,主机交换数据必须建立一个会话。它用比特流通信,即数据

被作为无结构的字节流。通过每个TCP 传输的字段指定顺序号,以获得可靠性。是在OSI

参考模型中的第四层,TCP 是使用IP 的网间互联功能而提供可靠的数据传输,IP 不停的把

报文放到网络上,而TCP 是负责确信报文到达。在协同IP 的 *** 作中TCP 负责:握手过程、

报文管理、流量控制、错误检测和处理(控制),可以根据一定的编号顺序对非正常顺序的

报文给予从新排列顺序。关于TCP 的RFC 文档有RFC793、RFC791、RFC1700。

在TCP 会话初期,有所谓的“三握手”:对乎悄每次发送的数据量是怎样跟踪进行协商使

数据段的发送和接收同步,根据所接收到的数据量而确定的数据确认数及数据发送、接收完

毕后何时撤消联系,并建立虚连接。为了提供可靠的传送,TCP 在发送新的数据之前,以

特定的顺序将数据包的序号,并需要这些包传送给目标机之后的确认消息。TCP 总是用来

发送大批量的数据。当应用程序在收到数据后要做出确认时也要用到TCP。由于TCP 需要

时刻跟踪,这需要额外开销,使得TCP 的格式有些显得复杂。下面就让我们看一个TCP 的

经典案例,这是后来被称为MITNICK 攻击中KEVIN 开创了两种攻击技术:

TCP 会话劫持

SYN FLOOD(同步洪流)

在这里我们讨论的时TCP 会话劫持的问题。

先让我们明白TCP 建立连接的基本简单的过程。为了建设一个小型的模仿环境我们假

设有3 台接入互联网的机器。A 为攻击者 *** 纵的攻击机。B 为中介跳板机器(受信任的服务

器)。C 为受害者使用的机器(多是服务器),这里把C 机器锁定为目标机器。A 机器向B

机器发送SYN 包,请求建立连接,这时已经响应请求的B 机器会向A 机器回应SYN/ACK

表明同意建立连接,当A 机器接受到B 机器发送的SYN/ACK 回应时,发送应答ACK 建立

A 机器与B 机器的网络连接。这样一个两台机器之间的TCP 通话信道就建立成功了。

B 终端受信任的服务器向C 机器发起TCP 连接,A 机器对服务器发起SYN 信息,使

C 机器不能响应B 机器。在同时A 机器也向B 机器发送虚假的C 机器回应的激笑SYN 数据包,

接收到SYN 数据包的B 机器(被C 机器信任)开始发送应答连接建立的SYN/ACK 数据包,

这时C 机器正在忙于响应以前发送的SYN 数据而无暇回应B 机器,而A 机器的攻击者预

测出B 机器包的序列号(现在的TCP 序列号预测难度有所加大)假冒C 机器向B 机器发送

应答ACK 这时攻击者骗取B 机器的信任,假冒岁铅渣C 机器与B 机器建立起TCP 协议的对话连

接。这个时候的C 机器还是在响应攻击者A 机器发送的SYN 数据。

TCP 协议栈的弱点:TCP 连接的资源消耗,其中包括:数据包信息、条件状态、序列

号等。通过故意不完成建立连接所需要的三次握手过程,造成连接一方的资源耗尽。

通过攻击者有意的不完成建立连接所需要的三次握手的全过程,从而造成了C 机器的

资源耗尽。序列号的可预测性,目标主机应答连接请求时返回的SYN/ACK 的序列号时可预

测的。(早期TCP 协议栈,具体的可以参见1981 年出的关于TCP 雏形的RFC793 文档)

TCP 头结构

TCP 协议头最少20 个字节,包括以下的区域(由于翻译不禁相同,文章中给出

相应的英文单词):

TCP 源端口(Source Port):16 位的源端口其中包含初始化通信的端口。源端口和

源IP 地址的作用是标示报问的返回地址。

TCP 目的端口(Destination port):16 位的目的端口域定义传输的目的。这个端口指

明报文接收计算机上的应用程序地址接口。

TCP 序列号(序列码,Sequence Number):32 位的序列号由接收端计算机使用,重

新分段的报文成最初形式。当SYN 出现,序列码实际上是初始序列码(ISN),而第一个数

据字节是ISN+1。这个序列号(序列码)是可以补偿传输中的不一致。

TCP 应答号(Acknowledgment Number):32 位的序列号由接收端计算机使用,重

组分段的报文成最初形式。,如果设置了ACK 控制位,这个值表示一个准备接收的包的序

列码。

数据偏移量(HLEN):4 位包括TCP 头大小,指示何处数据开始。

保留(Reserved):6 位值域,这些位必须是0。为了将来定义新的用途所保留。

标志(Code Bits):6 位标志域。表示为:紧急标志、有意义的应答标志、推、重置

连接标志、同步序列号标志、完成发送数据标志。按照顺序排列是:URG、ACK、PSH、

RST、SYN、FIN。

窗口(Window):16 位,用来表示想收到的每个TCP 数据段的大小。

校验位(Checksum):16 位TCP 头。源机器基于数据内容计算一个数值,收信息机

要与源机器数值结果完全一样,从而证明数据的有效性。

优先指针(紧急,Urgent Pointer):16 位,指向后面是优先数据的字节,在URG

标志设置了时才有效。如果URG 标志没有被设置,紧急域作为填充。加快处理标示为紧急

的数据段。

选项(Option):长度不定,但长度必须以字节。如果没有选项就表示这个一字节

的域等于0。

填充:不定长,填充的内容必须为0,它是为了数学目的而存在。目的是确保空

间的可预测性。保证包头的结合和数据的开始处偏移量能够被32 整除,一般额外的零以保

证TCP 头是32 位的整数倍。

标志控制功能

URG:紧急标志

紧急(The urgent pointer) 标志有效。紧急标志置位,

ACK:确认标志

确认编号(Acknowledgement Number)栏有效。大多数情况下该标志位是置位的。

TCP 报头内的确认编号栏内包含的确认编号(w+1,Figure:1)为下一个预期的序列编号,同

时提示远端系统已经成功接收所有数据。

PSH:推标志

该标志置位时,接收端不将该数据进行队列处理,而是尽可能快将数据转由应用

处理。在处理telnet 或rlogin 等交互模式的连接时,该标志总是置位的。

RST:复位标志

复位标志有效。用于复位相应的TCP 连接。

SYN:同步标志

同步序列编号(Synchronize Sequence Numbers)栏有效。该标志仅在三次握手建立

TCP 连接时有效。它提示TCP 连接的服务端检查序列编号,该序列编号为TCP 连接初始端

(一般是客户端)的初始序列编号。在这里,可以把TCP 序列编号看作是一个范围从0 到4,

294,967,295 的32 位计数器。通过TCP 连接交换的数据中每一个字节都经过序列编号。

在TCP 报头中的序列编号栏包括了TCP 分段中第一个字节的序列编号。

FIN:结束标志

带有该标志置位的数据包用来结束一个TCP 回话,但对应端口仍处于开放状态,

准备接收后续数据。

服务端处于监听状态,客户端用于建立连接请求的数据包(IP packet)按照TCP/IP

协议堆栈组合成为TCP 处理的分段(segment)。

分析报头信息: TCP 层接收到相应的TCP 和IP 报头,将这些信息存储到内存中。

检查TCP 校验和(checksum):标准的校验和位于分段之中(Figure:2)。如果检验

失败,不返回确认,该分段丢弃,并等待客户端进行重传。

查找协议控制块(PCB{}):TCP 查找与该连接相关联的协议控制块。如果没有找

到,TCP 将该分段丢弃并返回RST。(这就是TCP 处理没有端口监听情况下的机制) 如果该

协议控制块存在,但状态为关闭,服务端不调用connect()或listen()。该分段丢弃,但不返

回RST。客户端会尝试重新建立连接请求。

建立新的socket:当处于监听状态的socket 收到该分段时,会建立一个子socket,

同时还有socket{},tcpcb{}和pub{}建立。这时如果有错误发生,会通过标志位来拆除相应

的socket 和释放内存,TCP 连接失败。如果缓存队列处于填满状态,TCP 认为有错误发生,

所有的后续连接请求会被拒绝。这里可以看出SYN Flood 攻击是如何起作用的。

丢弃:如果该分段中的标志为RST 或ACK,或者没有SYN 标志,则该分段丢弃。

并释放相应的内存。

发送序列变量

SND.UNA : 发送未确认

SND.NXT : 发送下一个

SND.WND : 发送窗口

SND.UP : 发送优先指针

SND.WL1 : 用于最后窗口更新的段序列号

SND.WL2 : 用于最后窗口更新的段确认号

ISS : 初始发送序列号

接收序列号

RCV.NXT : 接收下一个

RCV.WND : 接收下一个

RCV.UP : 接收优先指针

IRS : 初始接收序列号

当前段变量

SEG.SEQ : 段序列号

SEG.ACK : 段确认标记

SEG.LEN : 段长

SEG.WND : 段窗口

SEG.UP : 段紧急指针

SEG.PRC : 段优先级

CLOSED 表示没有连接,各个状态的意义如下:

LISTEN : 监听来自远方TCP 端口的连接请求。

SYN-SENT : 在发送连接请求后等待匹配的连接请求。

SYN-RECEIVED : 在收到和发送一个连接请求后等待对连接请求的确认。

ESTABLISHED : 代表一个打开的连接,数据可以传送给用户。

FIN-WAIT-1 : 等待远程TCP 的连接中断请求,或先前的连接中断请求的确认。

FIN-WAIT-2 : 从远程TCP 等待连接中断请求。

CLOSE-WAIT : 等待从本地用户发来的连接中断请求。

CLOSING : 等待远程TCP 对连接中断的确认。

LAST-ACK : 等待原来发向远程TCP 的连接中断请求的确认。

TIME-WAIT : 等待足够的时间以确保远程TCP 接收到连接中断请求的确认。

CLOSED : 没有任何连接状态。

TCP 连接过程是状态的转换,促使发生状态转换的是用户调用:OPEN,SEND,

RECEIVE,CLOSE,ABORT 和STATUS。传送过来的数据段,特别那些包括以下标记的数

据段SYN,ACK,RST 和FIN。还有超时,上面所说的都会时TCP 状态发生变化。

序列号

请注意,我们在TCP 连接中发送的字节都有一个序列号。因为编了号,所以可以

确认它们的收到。对序列号的确认是累积性的。TCP 必须进行的序列号比较 *** 作种类包括

以下几种:

①决定一些发送了的但未确认的序列号。

②决定所有的序列号都已经收到了。

③决定下一个段中应该包括的序列号。

对于发送的数据TCP 要接收确认,确认时必须进行的:

SND.UNA = 最老的确认了的序列号。

SND.NXT = 下一个要发送的序列号。

SEG.ACK = 接收TCP 的确认,接收TCP 期待的下一个序列号。

SEG.SEQ = 一个数据段的第一个序列号。

SEG.LEN = 数据段中包括的字节数。

SEG.SEQ+SEG.LEN-1 = 数据段的最后一个序列号。

如果一个数据段的序列号小于等于确认号的值,那么整个数据段就被确认了。而

在接收数据时下面的比较 *** 作是必须的:

RCV.NXT = 期待的序列号和接收窗口的最低沿。

RCV.NXT+RCV.WND:1 = 最后一个序列号和接收窗口的最高沿。

SEG.SEQ = 接收到的第一个序列号。

SEG.SEQ+SEG.LEN:1 = 接收到的最后一个序列号。


欢迎分享,转载请注明来源:内存溢出

原文地址:https://www.54852.com/yw/12274835.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-05-22
下一篇2023-05-22

发表评论

登录后才能评论

评论列表(0条)

    保存