tcp和udp的差异化Word格式.docx
《tcp和udp的差异化Word格式.docx》由会员分享，可在线阅读，更多相关《tcp和udp的差异化Word格式.docx（12页珍藏版）》请在冰豆网上搜索。
端口的划分使IP主机之间可用单个的IP地址实现不同类型的并发连接。
在绝大多数现代操作系统中，采用32位IP地址和16位端口地址的组合来确认一个接口。
源接口和目的接口的组合就定义了一个连接。
有216或65536个可能的端口。
最低的1024个端口是常用的，它们是系统为特定的应用层协议所保留的默认设置。
如：
默认状态下，HTTP使用端口80，而POP3使用端口110。
其它的应用可以使用编号更高的端口。
在接下来的两个域中，序列号和确认号是TCP实现可靠连接的关键。
当建立一个TCP连接时，发送方主机发出一个随机的初始化序列号给初始化器，初始化器将其加1后送回确认域的起始器，这意味着下一个字节可以发送了。
一旦数据开始流动，序列号和确认号将跟踪已发送了那些数据，那些数据已被确认。
因为每个域都是32位，总共可以有232个值，所以每个域的范围是：
0～4294967295，当超过上限时回到0。
4位的偏移量代表TCP头部一共有多少个32位的信息。
这个信息是必不可少的，因为有可选的头部区域，偏移量标识了头部的结束和数据的开始。
TCP的设计者保留了接下来的6位，以防万一将来要对其进行扩展。
实际上，自从RFC793（传输控制协议）1981年发布以来，还没人有恰当的理由使用这些位，在这一点上，Jon
Postel和他的同事一定是过分谨慎了。
随后的6位每个都是一个标志。
若UNG标志位的值为1，意味着远在头部紧急指针区域的数据是有效的；
若ACK标志位的值为1，则意味着确认号区域中的数据是有效的。
（注意：
一个SYN包有一个有意义的序列号，但它的确认号是无意义的，因为它并不确认任何事件）PSH标志位使数据不必等待发送和等待接收。
RST标志位将断开一个连接。
SYN（同步）标志位意味着序列号是有效的，FIN（结束）标志位将指出发送方已经发完了数据。
16位长的窗口区域表示了“滑动窗口”的大小，也就是告诉发送方它已经准备好接收多少个字的数据。
TCP通过调整窗口的大小来控制数据的流量。
一个值为0的窗口意味着通告发送方：
如果没有进一步的通知，接收器已满，不能再接收更多的数据了。
大的窗口可以确保在任何给定的时间传输多达65536个未经确认的字节，但是，当重发定时器超时且又没有得到接收确认时，窗口将减半，从而有效地降低传输速率。
16位的校验码区域保证了数据的完整性，保护了TCP头部和IP头部的各个区域。
发送方计算校验值并把它插入这个区域，接收方根据收到的包重新计算该值并比较二者，如果它们是匹配的，则认为数据是完整无损的。
当设置紧急标志位时，紧急指针是一个16位的偏移量，它代表必须加快的最后一个字。
选择区域可以容纳0或多个32位字，可扩展TCP的性能。
大多数常用的选择区域支持大于65536字节的窗口，从而缩短了等待确认的时间，尤其是在高传输率时。
TCP的传输机构有多个定时器。
当一个包发送时，重发定时器开始计数；
当收到确认信号后，重发定时器停止计数。
如果超过设定时间段还没有收到确认信号，就重发该包。
一个比较棘手的问题是如何设置该时间段。
如果太长，当网络传输错误增加时将导致不必要的等待时间；
如果太短，就会产生过多的重复包从而降低网络的反应时间。
现代TCP协议根据实际情况对重发定时器进行动态设定。
持续定时器对于避免死锁是必不可少的。
如果网络收到了一个大小为0的窗口确认并且丢失了随后的重发数据的确认，持续定时器将超时并发送一个探针。
探针的回应将指出窗口的大小（也许仍为0）。
保持定时器在本端没有任何活动后，将检查在连接的另一端是否还有运行的进程。
如果没有任何回应，该定时器将断开连接。
当断开一个连接时，断开连接定时器将包的最大生命期加倍。
该定时器在连接断开之前确保流量最大。
不管重发过程执行得多么有效，很少的丢失包就能严重地降低TCP连接的流量。
每个未收到的包或包的片段只会在重发定时器超时的时候才会丢失。
在数据重发时，接收过程一直在递送这些重发的数据，这样就使总体的数据传输陷于停顿，直到丢失的数据被取代为止。
这些重发过程导致基于TCP的连接有时处于不稳定状态。
TCP与UDP的选择
如果比较UDP包和TCP包的结构，很明显UDP包不具备TCP包复杂的可靠性与控制机制。
与TCP协议相同，UDP的源端口数和目的端口数也都支持一台主机上的多个应用。
一个16位的UDP包包含了一个字节长的头部和数据的长度，校验码域使其可以进行整体校验。
（许多应用只支持UDP，如：
多媒体数据流，不产生任何额外的数据，即使知道有破坏的包也不进行重发。
）
很明显，当数据传输的性能必须让位于数据传输的完整性、可控制性和可靠性时，TCP协议是当然的选择。
当强调传输性能而不是传输的完整性时，如：
音频和多媒体应用，UDP是最好的选择。
在数据传输时间很短，以至于此前的连接过程成为整个流量主体的情况下，UDP也是一个好的选择，如：
DNS交换。
把SNMP建立在UDP上的部分原因是设计者认为当发生网络阻塞时，UDP较低的开销使其有更好的机会去传送管理数据。
TCP丰富的功能有时会导致不可预料的性能低下，但是我们相信在不远的将来，TCP可靠的点对点连接将会用于绝大多数的网络应用。
网络管理之TCP/UDP篇
我们学习过什么是“数据包”。
理解数据包，对于网络管理的网络安全具有至关重要的意义。
比如，防火墙的作用本质就是检测网络中的数据包，判断其是否违反了预先设置的规则，如果违反就加以阻止。
图1就是瑞星个人版防火墙软件设置规则的界面。
细心的读者会发现，图1中的“协议”栏中有“TCP”、“UDP”等名词，它们是什么意思呢？
现在我们就来讲讲什么是TCP和UDP。
面向连接的TCP
“面向连接”就是在正式通信前必须要与对方建立起连接。
比如你给别人打电话，必须等线路接通了、对方拿起话筒才能相互通话。
图1
TCP（TransmissionControlProtocol，传输控制协议）是基于连接的协议，也就是说，在正式收发数据前，必须和对方建立可靠的连接。
一个TCP连接必须要经过三次“对话”才能建立起来，其中的过程非常复杂，我们这里只做简单、形象的介绍，你只要做到能够理解这个过程即可。
我们来看看这三次对话的简单过程：
主机A向主机B发出连接请求数据包：
“我想给你发数据，可以吗？
”，这是第一次对话；
主机B向主机A发送同意连接和要求同步（同步就是两台主机一个在发送，一个在接收，协调工作）的数据包：
“可以，你什么时候发？
”，这是第二次对话；
主机A再发出一个数据包确认主机B的要求同步：
“我现在就发，你接着吧！
”，这是第三次对话。
三次“对话”的目的是使数据包的发送和接收同步，经过三次“对话”之后，主机A才向主机B正式发送数据。
TCP协议能为应用程序提供可靠的通信连接，使一台计算机发出的字节流无差错地发往网络上的其他计算机，对可靠性要求高的数据通信系统往往使用TCP协议传输数据。
图2
我们来做一个实验，用计算机A（安装Windows2000Server操作系统）从“网上邻居”上的一台计算机B拷贝大小为8,644,608字节的文件，通过状态栏右下角网卡的发送和接收指标就会发现：
虽然是数据流是由计算机B流向计算机A，但是计算机A仍发送了3,456个数据包，如图2所示。
这些数据包是怎样产生的呢？
因为文件传输时使用了TCP/IP协议，更确切地说是使用了面向连接的TCP协议，计算机A接收数据包的时候，要向计算机B回发数据包，所以也产生了一些通信量。
图3
如果事先用网络监视器监视网络流量，就会发现由此产生的数据流量是9,478,819字节，比文件大小多出10.96%（如图3所示），原因不仅在于数据包和帧本身占用了一些空间，而且也在于TCP协议面向连接的特性导致了一些额外的通信量的产生。
面向非连接的UDP协议
“面向非连接”就是在正式通信前不必与对方先建立连接，不管对方状态就直接发送。
这与现在风行的手机短信非常相似：
你在发短信的时候，只需要输入对方手机号就OK了。
UDP（UserDataProtocol，用户数据报协议）是与TCP相对应的协议。
它是面向非连接的协议，它不与对方建立连接，而是直接就把数据包发送过去！
图4
UDP适用于一次只传送少量数据、对可靠性要求不高的应用环境。
比如，我们经常使用“ping”命令来测试两台主机之间TCP/IP通信是否正常，其实“ping”命令的原理就是向对方主机发送UDP数据包，然后对方主机确认收到数据包，如果数据包是否到达的消息及时反馈回来，那么网络就是通的。
例如，在默认状态下，一次“ping”操作发送4个数据包（如图2所示）。
大家可以看到，发送的数据包数量是4包，收到的也是4包（因为对方主机收到后会发回一个确认收到的数据包）。
这充分说明了UDP协议是面向非连接的协议，没有建立连接的过程。
正因为UDP协议没有连接的过程，所以它的通信效果高；
但也正因为如此，它的可靠性不如TCP协议高。
QQ就使用UDP发消息，因此有时会出现收不到消息的情况。
附表：
tcp协议和udp协议的差别
TCP协议和UDP协议各有所长、各有所短，适用于不同要求的通信环境。
TCP协议和UDP协议之间的差别如附表所示。
通过连接实例解读TCP/IP协议
最近狂补基础，猛看TCP/IP协议。
不过，书上的东西太抽象了，没有什么数据实例，看了不
久就忘了。
于是，搬来一个sniffer，抓了数据包来看，呵呵，结合书里面得讲解，理解得
比较快。
我就来灌点基础知识。
开始吧，先介绍IP协议。
IP协议（InternetProtocol）是网络层协议，用在因特网上，TCP，UDP，ICMP，IGMP数
据都是按照IP数据格式发送得。
IP协议提供的是不可靠无连接得服务。
IP数据包由一个头部
和一个正文部分构成。
正文主要是传输的数据，我们主要来理解头部数据，可以从其理解到
IP协议。
IP数据包头部格式（RFC791）
ExampleInternetDatagramHeader
上面的就是IP数据的头部格式，这里大概地介绍一下。
IP头部由20字节的固定长度和一个可选任意长度部分构成，以大段点机次序传送，从左到
右。
TCP协议
TCP协议（TRANSMISSIONCONTROLPROTOCOL）是传输层协议，为应用层提供服务，和UDP
不同的是，TCP协议提供的可靠的面向连接的服务。
在RFC793中是基本的TCP描述。
关于TCP
协议的头部格式内容的说明：
TCPHeaderFORMat
TCPHeaderFORMat
跟IP头部差不多，基本的长度也是20字节。
TCP数据包是包含在一个IP数据报文中的。
好了，简单介绍到此为止。
来看看我捕获的例子吧。
这是一次FTP的连接，呵呵，是
cuteftp默认的cuteftp的FTP站点，IP地址是：
216.3.226.21。
我的IP地址假设为：
192.168.1.1。
下面的数据就是TCO/IP连接过程中的数据传输。
我们可以分析TCP/IP协议数
据格式以及TCP/IP连接的三次握手（ThreeWay-Handshake）情况。
下面的这些十六进制数据
只是TCP/IP协议的数据，不是完整的网络通讯数据。
第一次，我向FTP站点发送连接请求（我把TCP数据的可选部分去掉了）
192.168.1.1->
216.3.226.21
IP头部：
450000305252400080062c23c0a80101d803e215
TCP头部：
0d280015505fa9060000000070024000c0290000
来看看IP头部的数据是些什么。
第一字节，“45”，其中“4”是IP协议的版本（Version），说明是IP4。
“5”是IHL
位，表示IP头部的长度，是一个4bit字段，最大就是1111了，值为12，IP头部的最大长度就
是60字节。
而这里为“5”，说明是20字节，这是标准的IP头部长度，头部报文中没有发送
可选部分数据。
接下来的一个字节“00”是服务类型（TypeofService）。
这个8bit字段由3bit的优先
权子字段（现在已经被忽略），4bit的TOS子字段以及1bit的未用字段（现在为0）构成。
4bit的TOS子字段包含：
最小延时、最大吞吐量、最高可靠性以及最小费用构成，这四个1
bit位最多只能有一个为1，本例中都为0，表示是一般服务。
接着的两个字节“0030”是IP数据报文总长，包含头部以及数据，这里表示48字节。
这
48字节由20字节的IP头部以及28字节的TCP头构成（本来截取的TCP头应该是28字节的，其中
8字节为可选部分，被我省去了）。
因此目前最大的IP数据包长度是65535字节。
再是两个字节的标志位（Identification）：
“5252”，转换为十进制就是21074。
这个
是让目的主机来判断新来的分段属于哪个分组。
下一个字节“40”，转换为二进制就是“01000000”，其中第一位是IP协议目前没有用
上的，为0。
接着的是两个标志DF和MF。
DF为1表示不要分段，MF为1表示还有进一步的分段
（本例为0）。
然后的“00000”是分段便移（FragmentOffset）。
“80”这个字节就是TTL（TimeToLive）了，表示一个IP数据流的生命周期，用Ping显
示的结果，能得到TTL的值，很多文章就说通过TTL位来判别主机类型。
因为一般主机都有默
认的TTL值，不同系统的默认值不一样。
比如WINDOWS为128。
不过，一般Ping得到的都不是
默认值，这是因为每次IP数据包经过一个路由器的时候TTL就减一，当减到0时，这个数据包
就消亡了。
这也时Tracert的原理。
本例中为“80”，转换为十进制就是128了，我用的
WIN2000。
继续下来的是“06”，这个字节表示传输层的协议类型（Protocol）。
在RFC790中有定
义，6表示传输层是TCP协议。
“2c23”这个16bit是头校验和（HeaderChecksum）。
接下来“c0a80101”，这个就是源地址（SourceAddress）了，也就是我的IP地址。
转换为十进制的IP地址就是：
192.168.1.1，同样，继续下来的32位“d803e215”是目标
地址，216.3.226.21
好了，真累啊，终于看完基本的20字节的IP数据报头了。
继续看TCP的头部吧，这个是作
为IP数据包的数据部分传输的。
一来就是一个两字节段“0d28”，表示本地端口号，转换为十进制就是3368。
第二个两
字节段“0015”表示目标端口，因为我是连接FTP站点，所以，这个就是21啦，十六进制当
然就是“0015”。
接下来的四个字节“505fa906”是顺序号（SequenceNumber），简写为SEQ，
SEQ=1348446470
下面的四个字节“00000000”是确认号（AcknowledgmentNumber），简写为
ACKNUM。
继续两个字节，“7002”，转换为二进制吧，“0111000000000010”。
这两个字节，
总共16bit，有好多东西呢。
第一个4bit“0111”，是TCP头长，十进制为7，表示28个字节
（刚才说了，我省略了8字节的option数据，所以你只看见了20字节）。
接着的6bit现在TCP
协议没有用上，都为0。
最后的6bit“000010”是六个重要的标志。
这是两个计算机数据交
流的信息标志。
接收和发送断根据这些标志来确定信息流的种类。
下面是一些介绍：
URG：
（UrgentPointerfieldsignificant）紧急指针。
用到的时候值为1，用来处理避
免TCP数据流中断
ACK：
（Acknowledgmentfieldsignificant）置1时表示确认号（Acknowledgment
Number）为合法，为0的时候表示数据段不包含确认信息，确认号被忽略。
PSH：
（PushFunction），PUSH标志的数据，置1时请求的数据段在接收方得到后就可直
接送到应用程序，而不必等到缓冲区满时才传送。
RST：
（Resettheconnection）用于复位因某种原因引起出现的错误连接，也用来拒绝
非法数据和请求。
如果接收到RST位时候，通常发生了某些错误。
SYN：
（Synchronizesequencenumbers）用来建立连接，在连接请求中，SYN=1，
ACK=0，连接响应时，SYN=1，ACK=1。
即，SYN和ACK来区分ConnectionRequest和
ConnectionAccepted。
FIN：
（Nomoredatafromsender）用来释放连接，表明发送方已经没有数据发送了。
这6个标志位，你们自己对号入座吧。
本例中SYN=1，ACK=0，当然就是表示连接请求了。
我们可以注意下面两个过程的这两位的变换。
后面的“4000c0290000”不讲了，呵呵，偷懒了。
后面两次通讯的数据，自己分开看吧。
我们看看连接的过程，一些重要地方的变化。
第二次，FTP站点返回一个可以连接的信号。
216.3.226.21->
192.168.1.1
4500002cc6be40006a06cdbad803e215c0a80101
00150d284b4f45c1505fa9076012205864070000
第三次，我确认连接。
TCP连接建立起来。
450000285253400080062c2ac0a80101d803e215
0d280015505fa9074b4f45c2501040b05b1c0000
好，我们看看整个Threeway_handshake过程。
第一步，我发出连接请求，TCP数据为：
SEQ=505fa906，ACKNUM=00000000，
SYN=1，ACK=0。
第二步，对方确认可以连接，TCP数据为：
SEQ=4b4f45c1，ACKNUM=505fa907，
SYN=1，ACK=1。
第三步，我确认建立连接。
SEQ=505fa907，ACKNUM=4b4f45c2，SYN=0，ACK=1。
可以看出什么变化么？
正式建立连接了呢，这些东西是什么值？
我接收从216.3.226.21->
192.168.1.1的下一个数据包中：
SEQ=4b4f45c2，ACKNUM=505fa907,SYN=0,ACK=1
这些都是很基础的东西，对于编写sniffer这样的东西是必须非常熟悉的。
这里只讲解了
TCP/IP协议的一点点东西，主要是头部数据的格式。
升级会员 