关闭

TCP、UDP

标签: tcpudp
512人阅读 评论(0) 收藏 举报
分类:

1、TCP协议

1、1 TCP的工作过程

    首先TCP是一种面向连接的,可靠的,基于字节流的传输层通信协议。TCP的工作过程可以分为三个阶段:一、连接的建立;  二、传输数据; 三、断开连接

1、1、1 连接的建立

    TCP的连接建立就像打电话一样,我们打电话时,拨一个号码并不是立即就可以接通的,期间会有一个“嘟 嘟”的呼叫过程, 这就好比是TCP协议的连接的建立阶段。当我们用TCP编写的程序,必须先建立TCP连接。TCP协议的连接建立通过三次握手来完成的,也就是说,在收发数据前,必须和对方建立可靠的连接。其中的过程非常复杂,只简单的描述下这三次对话的简单过程:

1、主机A向主机B发出连接请求数据包:“我想给你发数据,可以吗?”,这是第一次对话;

2、主机B向主机A发送同意连接和要求同步(同步就是两台主机一个在发送,一个在接收,协调工作)的数据包:“可以,你什么时候发?”,这是第二次对话;

3、主机A再发出一个数据包确认主机B的要求同步:“我现在就发,你接着吧!”,这是第三次对话。三次“对话”的目的是使数据包的发送和接收同步,经过三次“对话”之后,主机A才向主机B正式发送数据。


具体步骤:

1、A 的 TCP 向 B 发出连接请求报文段,其首部中的同步位 SYN = 1,并选择序号 seq = x,表明传送数据时的第一个数据字节的序号是 x。A进入SYN_Send状态,等待服务器确认。主机A告诉主机B 两件事:我想要和你通信;你可以用哪个序列号作为起始数据段来回应我.

2、B 的 TCP 收到连接请求报文段后,如同意,则发回确认(B 在确认报文段中应使 SYN = 1,使 ACK = 1,其确认号ack = x﹢1,自己选择的序号 seq = y)此时服务器进入SYN_Recv状态。B也告诉主机A两件事:我已经收到你的请求了,你可以传输数据了;你要用哪个序列号作为起始数据段来回应我

3、A 收到此报文段后向 B 给出确认,其 ACK = 1,确认号 ack = y﹢1(A 的 TCP 通知上层应用进程,连接已经建立,B 的 TCP 收到主机 A 的确认后,也通知其上层应用进程:TCP 连接已经建立)客户端和服务器进入Established(建立)状态,完成三次握手。


解析:

ACK  TCP报头的控制位之一,对数据进行确认.确认由目的端发出,用它来告诉发送端这个序列号之前的数据段都收到了.比如,确认号为X,则表示前X-1个数据段都收到了,只有当ACK=1时,确认号才有效,当ACK=0时,确认号无效,这时会要求重传数据,保证数据的完整性.

SYN  同步序列号,TCP建立连接时将这个位置1

FIN  发送端完成发送任务位,当TCP完成数据传输需要断开时,提出断开连接的一方将这位置1

seq是数据包本身的序列号;

ack是期望对方继续发送的那个数据包的序列号。

在第一次消息发送中,A随机选取一个序列号作为自己的初始序号发送给B;第二次消息B使用ack对A的数据包进行确认,因为已经收到了序列号为x的数据包,准备接收序列号为x+1的包,所以ack=x+1,同时B告诉A自己的初始序列号,就是seq=y;第三条消息A告诉B收到了B的确认消息并准备建立连接,A自己此条消息的序列号是x+1,所以seq=x+1,而ack=y+1是表示A正准备接收B序列号为y+1的数据包。


3次握手的特点:没有应用层的数据、SYN这个标志位只有在TCP建产连接时才会被置1握手完成后SYN标志位被置0


1、1、2 传输数据
双方建立了连接,即在双方建立了一个通信通道(就像一座桥一样,在两端建立了一个通路),建立连接之后,当然是传输我们需要传输的数据到对方的,这里就开始简单介绍下传输数据的过程。
    利用TCP传输数据时,数据是以字节流的形式进行传输,客户端与服务器端建立连接后,发送方需要先将发送的数据转换为字节流,然后将其发送给对方,发送数据时,可以通过程序不断地将数据流陆续写入TCP的发送缓冲中,然后TCP自动从发送缓冲中提取一定量的数据,将其组成TCP报文段发送到IP层,再通过IP层(也就是网络层)之下的网络接口发送出去;接受端从IP层接收到TCP报文段后,将其暂时保存在接受缓冲中,然后我们通过程序依次读取接受缓冲中的数据,从而达到相互通信的目的(简单的说就发送方把数据转换为数据流,再把数据流存储在发送缓冲中,然后传输层低层的协议从发送缓冲中读取数据把数据发送出去,然后接收端从底层接受到数据把数据存储在接收端的缓冲中,然后我们写的程序只是从缓冲中依次读取数据,然后显示出来,在客户端我们写代码做的事情是把数据写入Write写入发送端的缓冲中,然后服务器端(接收端)用Read方法在自己的缓冲中读取数据,用一句话概括,TCP的传输就是对数据的写——读操作),因为这样我感觉理解起来比较容易,对于刚开始接触TCP的朋友可以这样理解,然后再一句句话去扩展。


1、1、3 断开连接

发送完数据之后,最后就是断开连接了,断开一个连接需要经过四次挥手。


1、数据传输结束后,通信的双方都可释放连接.现在 A 的应用进程先向其 TCP 发出连接释放报文段,并停止再发送数据,主动关闭 TCP 连接(A 把连接释放报文段首部的 FIN = 1,其序号seq = u,等待 B 的确认)

2、B 发出确认,确认号 ack = u+1,而这个报文段自己的序号 seq = v(TCP 服务器进程通知高层应用进程.从 A 到 B 这个方向的连接就释放了,TCP 连接处于半关闭状态.B 若发送数据,A 仍要接收)

3、若 B 已经没有要向 A 发送的数据,其应用进程就通知 TCP 释放连接

4、A 收到连接释放报文段后,必须发出确认,在确认报文段中 ACK = 1,确认号 ack=w﹢1,自己的序号 seq = u + 1


注意:
TCP 连接必须经过时间 2MSL 后才真正释放掉(2MSL 的时间的用意 --- 为了保证 A 发送的最后一个 ACK 报文段能够到达 B.防止 “已失效的连接请求报文段”出现在本连接中.A 在发送完最后一个 ACK 报文段后,再经过时间 2MSL,就可以使本连接持续的时间内所产生的所有报文段,都从网络中消失.这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段)


为什么需要“三次握手”?
    在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误”。在另一部经典的《计算机网络》一书中讲“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。这两种不同的表述其实阐明的是同一个问题。
    谢希仁版《计算机网络》中的例子是这样的,“已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。”。主要目的防止server端一直等待,浪费资源。


为什么需要“四次挥手”?
    那可能有人会有疑问,在tcp连接握手时为何ACK是和SYN一起发送,这里ACK却没有和FIN一起发送呢?原因是因为tcp是全双工模式,接收到FIN时意味将没有数据再发来,但是还是可以继续发送数据。

1、2 握手,挥手过程中各状态介绍:

3次握手过程状态: 

LISTEN: 这个也是非常容易理解的一个状态,表示服务器端的某个SOCKET处于监听状态,可以接受连接了。 

SYN_SENT: 当客户端SOCKET执行CONNECT连接时,它首先发送SYN报文,因此也随即它会进入到了SYN_SENT状态,并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。(发送端)

SYN_RCVD: 这个状态与SYN_SENT遥想呼应这个状态表示接受到了SYN报文,在正常情况下,这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态,很短暂,基本上用netstat你是很难看到这种状态的,除非你特意写了一个客户端测试程序,故意将三次TCP握手过程中最后一个 ACK报文不予发送。因此这种状态时,当收到客户端的ACK报文后,它会进入到ESTABLISHED状态。(服务器端)

ESTABLISHED:这个容易理解了,表示连接已经建立了


4次挥手过程状态:(可参考下图):


FIN_WAIT_1:这个状态要好好解释一下,其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是:FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时,它想主动关闭连接,向对方发送了FIN报文,此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后,则进入到FIN_WAIT_2状态,当然在实际的正常情况下,无论对方何种情况下,都应该马上回应ACK报文,所以FIN_WAIT_1状态一般是比较难见到的,而FIN_WAIT_2状态还有时常常可以用netstat看到。(主动方)

FIN_WAIT_2:上面已经详细解释了这种状态,实际上FIN_WAIT_2状态下的SOCKET,表示半连接,也即有一方要求close连接,但另外还告诉对方,我暂时还有点数据需要传送给你(ACK信息),稍后再关闭连接。(主动方)

TIME_WAIT:表示收到了对方的FIN报文,并发送出了ACK报文,就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下,收到了对方同时带FIN标志和ACK标志的报文时,可以直接进入到TIME_WAIT状态,而无须经过FIN_WAIT_2状态。(主动方)

CLOSING(比较少见): 这种状态比较特殊,实际情况中应该是很少见,属于一种比较罕见的例外状态。正常情况下,当你发送FIN报文后,按理来说是应该先收到(或同时收到)对方的 ACK报文,再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后,并没有收到对方的ACK报文,反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢?其实细想一下,也不难得出结论:那就是如果双方几乎在同时close一个SOCKET的话,那么就出现了双方同时发送FIN报文的情况,也即会出现CLOSING状态,表示双方都正在关闭SOCKET连接。

CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢?当对方close一个SOCKET后发送FIN报文给自己,你系统毫无疑问地会回应一个ACK报文给对方,此时则进入到CLOSE_WAIT状态。接下来呢,实际上你真正需要考虑的事情是察看你是否还有数据发送给对方,如果没有的话,那么你也就可以 close这个SOCKET,发送FIN报文给对方,也即关闭连接。所以你在CLOSE_WAIT状态下,需要完成的事情是等待你去关闭连接。(被动方)

LAST_ACK: 这个状态还是比较容易好理解的,它是被动关闭一方在发送FIN报文后,最后等待对方的ACK报文。当收到ACK报文后,也即可以进入到CLOSED可用状态了。(被动方)

CLOSED: 表示连接中断。


2、UDP协议

2、1 UDP介绍

UDP与TCP地位相当的另一个传输层协议,它也是当下流行的很多主流网络应用(例如QQ、MSN和Skype等一些即时通信软件传输层都是应用UDP协议的)底层的传输基础,
UDP和TCP都是构建在IP层之上传输层的协议,但UDP是一种简单、面向数据报(Sock_Dgram)的无连接协议,提供的是不一定可靠的传输服务

(1) UDP是一个非连接的协议,传输数据之前源端和终端不建立连接,当它想传送时就简单地去抓取来自应用程序的数据,并尽可能快地把它扔到网络上。在发送端,UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制;在接收端,UDP把每个消息段放在队列中,应用程序每次从队列中读一个消息段。
(2) 由于传输数据不建立连接,因此也就不需要维护连接状态,包括收发状态等,因此一台服务机可同时向多个客户机传输相同的消息
(3) UDP信息包的标题很短,只有8个字节,相对于TCP的20个字节信息包的额外开销很小
(4) 吞吐量不受拥挤控制算法的调节,只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。
(5)UDP使用尽最大努力交付,即不保证可靠交付,因此主机不需要维持复杂的链接状态表(这里面有许多参数)。
(6)UDP是面向报文的。发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付给IP层。既不拆分,也不合并,而是保留这些报文的边界,因此,应用程序需要选择合适的报文大小。


2、2 UDP的工作原理
    UDP将网络数据流量压缩成数据报的形式,每一个数据报用8个字节(8 X 8位=64位)描述报头信息,剩余字节包含具体的传输数据。UDP报头(只有8个字节)相当于TCP的报头(至少20个字节)很短,UDP报头由4个域组成,每个域各占2个字节,具体为源端口、目的端口、用户数据报长度和校验和,
具体结构见下图(下面也贴出了TCP报文的结构图,与UDP数据报做一个对比的作用):



UDP协议和TCP协议都使用端口号为不同的应用保留其各自的数据传输通道这一机制,数据发送方将UDP数据报通过源端口发送出去,而数据接收方则通过目标端口接收数据。


2、3 UDP与TCP的比较

(1)UDP的可靠性不如TCP,因为TCP传输前要首先建立连接,这样就增加了TCP传输的可靠性,所以UDP也被称为不可靠的传输协议
(2)UDP不能保证有序传输。即UDP不能确保数据的发送和接收顺序。
(3)UDP速度比TCP快。由于UDP不需要先与对方建立连接,也不需要传输确认,因此其数据的传输速度比TCP快很多。对于一些着重传输性能而不是传输完整性的应用(网络音频播放、视频点播和网络会议等),使用UDP协议更加适合,因为它传输速度快,使通过网络播放的视频音质好、画面清晰。
(4)UDP不需考虑消息边界。通过UDP协议进行传输的发送方对应用程序交下来的报文,在添加首部后就向下直接交付给IP层。既不拆分也不合并,而是保留这些报文的边界,所以使用UDP协议不需要像TCP那样考虑消息边界的问题,这样就使得UDP编程相对于TCP在接收到的数据处理方面要简单的多。
(5)UDP可以一对多传输。由于传输数据部建立连接,也就不需要维护连接状态,因此一台服务器可以同时向多个客户端发送相同的信息。利用UDP可以使用广播或者组播的方式同时向子网的所有客户端进程发送信息。
(6)UDP报头8字节比TCP报头20字节小。


上面介绍了UDP协议相对于TCP协议的优势,其中速度快是UDP的最重要的优势,也是像一些网络会议、即时通信软件传输层选择UDP协议进行传输的原因所在。




参考来源:

[C# 网络编程系列]专题五:TCP编程  

TCP为什么需要3次握手与4次挥手  

TCP协议与UDP协议的区别  

(传输层)TCP协议







0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:74856次
    • 积分:1652
    • 等级:
    • 排名:千里之外
    • 原创:89篇
    • 转载:15篇
    • 译文:0篇
    • 评论:26条
    最新评论