UDP及TCP详析

一、UDP

1.UDP段格式

2.UDP协议

     UDP协议是不面向连接，也不保证传输的可靠性，是不可靠的传输层协议。

     发送端UDP协议层值只管把应用层传来的数据封装成段交给IP协议层。若网络故障无法发送给对方，UDP协议层也不会给应用层返回任何错误消息。同样，接收端的UDP也只管把收到的数据根据端口号交给相应的应用程序。若发送端发来多个数据包且达到接收端顺序已经混乱了，UDP也不保证发送时的顺序交给应用层。

     使用UDP协议的应用程序必须考虑到UDP协议的问题提出解决方案，例如：等待应答、超时重发。为数据包编号、流量控制等。一般使用UDP协议的应用实现都比较简单，知识发送一些相对可靠性要求不高的数据，而不大量发送数据。

３.ＵＤＰ层传输过程

     Ａ主机向Ｂ主机发送数据包过程：

     用户把自己的数据交给传输层，传输层加上自己的头部，ＵＤＰ再交给ＩＰ层－－＞（网络层）ＩＰ层收到数据后，再加上自己的头部，交给ＭＡＣ帧－－＞（链路层）ＭＡＣ帧收到数据后，再加头部，交给Ｂ网络－－＞Ｂ链路层得到数据后，去掉自己能辨识的头部，交给ＩＰ层－－＞ＩＰ层去头，交给ＵＤＰ－－＞ＵＤＰ表头定长，根据有效载荷（端口号）交给对应程序－－＞用户层

     若A和B不在一个局域网，用路由器G1连接：

     每个主机都是一个路由器，能够决策数据的下个层是什么，主机先把数据传给G1（主机添加MAC帧头部），Ｇ１收到数据帧进行转发（查找路由表，触发ＡＲＰ地址解析协议，得到主机Ｂ地址，加头部信息），主机Ｂ收到数据再自底向上传递。

     在这个过程中ＩＰ地址没变过，不过ＭＡＣ地址一直变化（目标地址在不断变化）

４.TFTP协议（简单文件传输协议）

     TFTP基于UDP协议，端口号69。

     由于TFTP基于UDP，UDP使用IP，IP还可基于其他通信方法，所以TFTP包中分为以下几段：

     本地媒介头、IP头、数据报头。TFTP头、TFTP数据

二、TCP协议（传输控制）

1.段格式

• 一个ＴＣＰ报头２０字节
• 有１６位源端口和１６位目的端口号
• ３２位序号和３２为确认序号：ＴＣＰ是保证可靠性，是基于请求和应答的，面向连接的，对数据段进行编号保证按序到达，数据报具有流量控制机制（不会丢包）、网络拥塞算法、定时器。
• 六个标识位：
• • ＵＲＧ：表示ｕｒｇｅｎｔ　ｐｏｉｎｔｅｒ字段有意义，urg=1表示紧急指针指向包内数据段的某个字节（数据从第一字节到指针所指字节就是紧急数据，不进入接受缓冲直接交给上层进程，余下的数据要进入接受缓冲）
  • ＡＣＫ：表示Ａｃｋｎｏｗｌｅｄｇｅ　Ｎｕｍｂｅｒ有意义
  • ＰＳＨ：表示Ｐｕｓｈ功能，表尽快处理，PSH=1表示把接收缓冲中排好序的那一段交给上层。
  • ＰＳＴ：表示复位ＴＣＰ连接。
  • ＳＹＮ：表示ＳＹＮ报文（建立ＴＣＰ连接时使用）
  • ＦＩＮ：表示没有数据要发送（关闭ＴＣＰ连接时使用）

2.TCP介绍

     TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议

     TCP层位于IP层和应用层中间，不同主机应用层之间需要可靠、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。应用层向TCP发送用于网间传输的、用8位字节表示的数据流，然后TCP把数据分成适当长度的报文段（受计算机连接的网络的数据链路层的最大传输单元MTU限制），之后TCP把包传给IP层，由它来通过网络将包传送给接受实体的TCP层。TCP层为了不发生丢包，会给每个包一个序号，同时序号也保证了传送到实体的包按顺序接收、然后接收端实体对以成功接收的包发回一个相应的确认（ACK）。若发送端实体在合理的往返时延（RTT）内未收到确认，那么对应的数据包会被假设已丢并重新传。

     TCP用一个校验和函数来确认数据是否有错误，在接收和发送都需要计算校验和。

３.ＴＣＰ保证可靠机制

• 应用数据被ＴＣＰ分为最合适发送的数据块。ＴＣＰ传给ＩＰ的信息单位为报文段。
• TCP发送一个段后，启动一个定时器，等待目的端确认收到这个报文段。
• TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检查数据在传输过程中任何变化，若收到段的检验有差错，TCP将丢弃这个报文段。
• TCP将堆收到的数据重新排序，将收到的数据以正确的顺序交给应用层。
• IP数据报若发生重复，TCP丢弃重复数据
• 提供流量控制。防止较快主机致使较慢主机的缓冲区溢出

４.ＴＣＰ三次握手

     ＴＣＰ是传输层协议，使用三次握手建立连接。

• 客户端发送ＳＹＮ（ＳＥＱ＝ｘ）报文给服务器，进入ＳＹＮ＿ＳＥＮＤ状态。
• 服务器收到ＳＹＮ报文回应一个ＳＹＮ（ＳＥＱ＝ｙ）＋ＡＣＫ（ＡＣＫ＝ｘ＋１）报文，进入ＳＹＮ＿ＲＥＣＶ状态
• 客户端收到ＳＹＮ报文，回应一个ＡＣＫ（ＡＣＫ＝ｙ＋１）报文，进入Ｅｓｔａｂｌｉｓｈｅｄ状态
• 三次握手完成，建立连接，可传输数据

*为啥不能2次握手？4次握手呢？

     当Ａ要连接到Ｂ，结果发生的连接信息由于某种原因没达到Ｂ机；于是Ａ又重发一次，Ｂ收到，于是发信息回来，两机连接，传完东西后断开。这时之前没到达的信息又传到Ｂ机，Ｂ机发消息给A，B机又以为和A连上了，这时候B机就在等待Ａ传东西，浪费资源。

     若为四次握手也可以，不过这样过于繁琐，只需要三次握手就能高效又节省资源的连接。

 ＴＣＰ通讯中，若一方收到另一方发来的段，读出其中的目的端口号，发现本机并没有任何的进程使用这个端口，就会应答一个包含ＲＳＴ位的段给另一方。

     服务器没有任何进程使用８０８０端口，所以用ｔｅｌｎｅｔ客户端去连接它，服务器收到客户端发来的ＳＹＮ段，应答一个ＲＳＴ段，客户端的ｔｅｌｎｅｔ收到ＲＳＴ段后报告错误

５.四次挥手

• 某个应用进行首先调用ｃｌｏｓｅ，称该端执行“主动关闭”，该端ＴＣＰ发送一个ＦＩＮ分节表示数据发送完毕。
• 接受到这个ＦＩＮ的对端执行“被动关闭”，这个ＦＩＮ由ＴＣＰ确认。
• 一段时间后，接受到这个文件描述符的应用程序调用ｃｌｏｓｅ关闭它的套接字，这导致它的ＴＣＰ也发送一个ＦＩＮ。
• 接受到最终ＦＩＮ的原发送端ＴＣＰ确认这个ＦＩＮ

*为啥要四次挥手

     由于TCP是全双工的，接收到FIN意味没有数据再发，但是还可以继续发送数据。

5.TCP状态变迁