如何实现一个tcpudp客户端和服务器,以及它们之间是如何交互

如何实现一个tcpudp客户端和服务器,以及它们之间是如何交互,第1张

  你先要了解一下网络协议。你这说的是传输层的协议,TCP和UDP都是固定端口的。网络分成好多层的,每层的端口都不一样,每一层将会把低一层的数据封装打包,这个就是所谓的协议,不同功能的软件和硬件处理自己这层的端口和数据,然后再传递给上层。每一层协议不相关,也不需要知道和理解传来的是什么,只负责自己的规则就好,传过来的都当成数据处理打包。RTSP是应用层的协议,在TCP和UDP之上层,可以自定义端口,一般是554。系统自己会处理TCP和UDP数据,socket都已经实现好了,然后再将RTSP的协议数据通过端口554给你客户端。所以你不用太关心TCP和UDP层的东西,如果你发烧无聊,也可以自己实现TCP和UDP协议,抓取数据,得到RTSP的数据包,就是RTSP协议层部分了。获取到RTSP的协议部分,通过RTSP的协议,分析出命令和数据部分,这个就是基本解析过程。

原理四个主要方面:

一、tcp协议之连接建立、断开

二、tcp协议之超时重传

三、tcp协议之窗口管理

四、tcp协议之拥塞控制

TCP是一种面向有连接的协议,也就是说必须确认对方存在时才能发送数据而TCP通过检验和、序列号、确认应答、重发控制、连接管理、窗口控制等机制来实现可靠传输。

1 目的:TCP三次握手是客户端和服务器总共发三个数据包,通过三个数据包来确认主动发送能力和被动接收能力是否正常。

2 实质:通过指定的四元组(源地址、源端口、目标地址、目标端口)来建立TCP连接,同步双方各自发送序列号seq和确认号ACK,同时也会交换窗口大小信息

三次握手过程的实现方式就是交换序列号seq。

随便在网上找个地址,如果通过域名想看ip地址,可以ping下看连接。

① 19216837发送[SYN]报文段至222169228146,告知序列号x为0。

② 222169228146发送[SYN,ACK]报文段至19216837,告知序列号y为0,确认号ACK为x+1=1。

③19216837发送[ACK]报文段至222169228146,告知确认号ACK为y+1=1。

报文段中的其他参数:

MSS=1460 :允许从对方接收到的最大报文段,图中为1460字节(指承载的数据,不包含报文段的头部)。

win=8192 :滑动窗口的大小为8192字节。

SACK_PERM=1 :开启选择确认。为什么会使用SACK:tcp确认方式不是一段报文段一确认,而是采用累积确认方式。服务器接收到的报文段无序所以序列号也是不连续,服务器的接收队列会出现空洞情况。为了解决空洞,提前了解当前空洞,应对丢失遗漏,采取重传。提前了解方式就是通过SACK选项信息,SACK信息包含接收方已经成功接收的数据块的序列号范围。而SACK_PERM字段为1表明,选择开启了SACK功能。

网络层可能会出现丢失、重复、乱序的问题,tcp是提供可靠的数据传输服务的,为了保证数据的正确性,tcp协议会重传它认为的已经丢失的包。重传两种机制:一种基于时间重传,一种基于确认报文段提供的信息重传。

RTT :数据完全发送完(完成最后一个比特推送到数据链路上)到收到确认信号的时间(往返时间)。

RTO :重传超时时间(tcp发送数据时设置一个计时器,当计时器超时没有收到数据确认信息,引发超时而重传,判断的标准就是RTO)。

思考:发送序列号为1、2、3、4这4个报文段,但是出现了序列号2报文段丢失,怎么办?

发送端接收到seq1的确认报文(ACK=2)后,等待seq=2的确认报文。

接收端当收到序列号为3的报文(2已丢失),发送ack为4的确认报文,发送端正等待ack为2的确认报文,面对跳跃的报文,那么发送端会一直等待,直到超出指定时间,重传报文2。

为什么不跳跃确认呢?

tcp是累积确认方式,如果确认报文3,那么意味着报文1和报文2都已经成功接收。

超时处理方式:

思考:上面计时器是以时间为标准重传,那么可以通过确认报文的次数来决定重传。

发送端接收到seq1的确认报文(ACK=2)后,等待seq=2的确认报文。

接收端收到报文3、4、5,但是没收到报文2,那么接收端发送三个ACK为2的确认报文,发送端收到这个三个确认报文,重传报文2。

思考:如果快速重传中丢失包的地方很多(报文2,报文,7,报文9,报文30,报文300),那么需要从头到尾都重传,这很蛋疼?

思考:SACK重传对于接收到重复数据段怎样运作没有明确规定,通过DSACK重传可以让发送方知道哪些数据被重复接收了,而且明确是什么原因造成的。

发送端没有收到100-199的ACK包,超过指定时间,重传报文。

接收端都已经收到200-299的发送报文了,又来100-199是重复报文。再向发送端发送一个ACK报文,设置SACK 100-199,告知发送端,已经收到了100-199包,只是回应ACK包丢失。

发送端发送包100-199,由于网络延迟,一直没有达到接收端。

接收端连续发送三个ACK 200确认报文,触发快速重传,发送端收到了ACK 500的确认报文,表明之前的报文都已经交付成功。

接收端又收到了延迟的报文100-199,再次向发送端发送一个SACK 100-199的ACK 500报文。

发送端发现这是重复报文,判断为网络延迟造成的。

计时器重传:根据超时,重传。

快速重传:根据接收三次相同ACK报文,重传。

选择确认重传:根据接收端提供的SACK信息,重传。

DSACK重传:根据重复报文,明确丢失ACK报文还是网络延迟。

Category1:已发送且已确认(已经收到ACK报文的数据)。

Category2:已发送但未收到确认。

Category3:即将发送。

Category4:窗口移动前都不能发送。

可用窗口:46-51字节。

发送窗口:32-51字节。

RCVNXT:左边界

RCVWND:接收窗口

RCVNXT+RCVWND:右边界

接收端接收到序列号小于左边界,那么被认为重复数据而被丢弃。

接收端接收到序列号大于右边界,那么被认为超出处理范围,丢弃。

注意:tcp协议为累积ACK结构,只有当达到数据序列号等于左边界时,数据才不会被丢弃。

如果窗口更新ACK丢失,对于发送端,窗口左边界右移,已发送数据得到ACK确认之后,左右边界距离减小,发送端窗口会减小,当左右边界相等时,称为零窗口。零窗口之后:接收端发送窗口更新能会发生窗口更新ACK丢失。

<<tcp/ip 详解>>解释:

TCP是通过接收端的通告窗口来实现流量控制的,通告窗口指示了接收端可接收的数据量。

当窗口值变为0时,可以有效阻止发送端继续发送,直到窗口大小恢复为非零值。

当接收端重新获得可用空间时,会给发送端传输一个窗口更新告知其可继续发送数据。这样的窗口更新通常都不包含数据(纯ACK),接收端向发送端发送的窗口更新ACK可能丢失。结果双方处于等待状态,发生死锁

解决方案:

发送端会采用一个持续计时器间歇性地查询接收端,看其窗口是否已增长。触发窗口探测,强制要求接收端返回ACK。发送几次探测,窗口大小还是0,那么断开连接。

出现SWS的情况:

① 接收端通告窗口太小。

② 发送端发送的数据太小。

解决方案:

① 针对接收端:不应通告小窗口值

[RFC1122]描述:在窗口可增至一个全长的报文段(接收端MSS)或者接收端缓存空间的一半(取两者中较小值)之前,不能通告比当前窗口更大的窗口值。标准:min(MSS , 缓存空间/2)。

② 针对发送端:不应发送小的报文

至少满足以下其一:

(1)可以发送MSS字节的报文。

window size >= MSS或者 数据大小>=MSS

(2)数据段长度>=接收端通告过的最大窗口值的一半,才可以发送。

收到之前发送的数据的ack回包,再发送数据,否则一直攒数据。

(3) -1 没有未经确认的在传数据或者-2 连接禁用Nagle算法。

tcp基于ACK数据包中的通告窗口大小字段实现了流量控制。

当网络大规模通信负载而瘫痪,默认网络进入拥塞状态,减缓tcp的传输。发送方和接收方被要求承担超负荷的通信任务时,采取降低发送速率或者最终丢弃部分数据的方法。

反映网络传输能力的变量称为拥塞窗口(cwnd)。

通告窗口(awnd)。

发送窗口swnd=min(cwnd,awnd)

目的:tcp在用拥塞避免算法探寻更多可用带宽之前得到cwnd值,帮助tcp建立ACK时钟。

[RFC5681] :在传输初始阶段,由于未知网络传输能力,需要缓慢探测可用传输资源,防止短时间内大量数据注入导致拥塞。慢启动算法针对这一问题而设计。在数据传输之初或者重传计时器检测到丢包后,需要执行慢启动。

拥塞窗口值:每收到一个ACK值,cwnd扩充一倍。所以假设没有丢包且每个数据包都有相应ACK值,在k轮后swnd= ,成 指数增长

SMSS是发送方的最大段大小。

慢启动阶段,cwnd会指数增长,很快,帮助确立一个慢启动阙值(ssthresh)。有了阙值,tcp会进入拥塞避免阶段,cwnd每次增长值近似于成功传输的数据段大小,成 线性增长

实现公式:cwnd+=SMSSSMSS/cwnd

刚建立连接使用慢启动算法,初始窗口为4,收到一次ACK后,cwnd变为8,再收到一次ACK后,cwnd变为16,依次继续,32、64,达到阙值ssthresh为64。

开始使用拥塞避免算法,设置ssthresh为ssthresh/2,值为32。重新从初始窗口4,线性递增到ssthresh=32。

当cwnd < ssthresh时,使用慢启动算法

当cwnd > ssthresh时,使用拥塞避免算法

应用快速恢复算法时机:启动快速重传且正常未失序ACK段达到之前。启动快速恢复算法。

实现过程:

① 将ssthresh设置为1/2 cwnd,将cwnd设置为ssthresh+3SMSS。

② 每接收一个重复ACK,cwnd值暂时增加1 SMSS。

③当接收到新数据ACK后,将cwnd设置为ssthresh。

参考:<<tcp/ip 详解>>

建议您使用delphi2010之后的Datasnap,基本思路:

1登录服务器时注册用户信道

2发送消息时,根据群单发两种情况,调用服务器不同方法CallBack,返回到客户端界面

描述不够详细, 是想用浏览器控制硬件还是监控场景 如果是控制硬件, 先是电脑与硬件的通信与控制,能够完成的同时, 基于Web服务进行开发, 如果用CS架构在开发Web服务的时候, 就完成服务控制了

至于TCP服务器, 你是指客户端与被控制端的通信么

在TCP/IP中,TCP协议通过三次握手来建立连接,从而提供可靠的连接服务。

第一次握手:建立连接后,客户端向服务器发送syn包(syn=j),进入SYN_SEND状态,等待服务器确认;

第二次握手:当服务器收到syn包时,必须确认客户端的syn(ack=j+1)并发送一个syn包(syn=k),即syn+ack包。此时,服务器进入SYN_RECV状态。

第三次握手:SYN+ACK包,客户端收到服务器端发来的确认包ACK(ACK=k+1),来发送这个包来发送,客户端和服务器端进入建立状态,完成三路握手。

扩展资料:

重要概念:

无关的队列:三重握手协议、服务器维护一个独立队列,为每个客户的SYN包创建一个条目(SYN=j)表明服务器已经收到了SYN包和确认发送到客户,等待客户的确认包。

这些条目标识的连接处于服务器的Syn_RECV状态,当服务器接收到客户机的确认包时,它将删除该条目,服务器将进入已建立的状态。

Backlog参数:表示要保持的未连接队列的最大数量。

当服务器发送synack包时,如果没有收到客户端确认包,服务器将进行第一次重传,等待一段时间仍然没有收到客户端确认包,然后进行第二次重传。

如果重传号超过系统指定的最大重传号,系统将从半连接队列中删除连接信息。注意每个重传的等待时间可能不相同。

半连接生存时间:指半连接队列中条目的最长生存时间,即从接收SYN包到确认无效消息的最长服务时间。这个时间值是所有重传请求包的最长等待时间的总和。有时我们也称半连接生存时间为超时时间,SYN_RECV生存时间。

服务器操作流程

客户端操作:

服务器操作:

客户端操作:

既有基于TCP的RTP,也有基于UDP的RTP,但抓包发现,VLC的RTP是基于UDP的。

操作模式与UDP一致。

VLC的http方式搭建的流媒体服务器是用TCP方式进行数据传输的,操作方式与RTSP一致。

DABAN RP主题是一个优秀的主题,极致后台体验,无插件,集成会员系统
网站模板库 » 如何实现一个tcpudp客户端和服务器,以及它们之间是如何交互

0条评论

发表评论

提供最优质的资源集合

立即查看 了解详情