TCP/UDP协议总结与应用层常见协议及端口

蔚落 2022-12-01 11:51 405阅读 0赞

### TCP/UDP协议总结与应用层常见协议及端口 ###

*  1、TCP协议
 *   *   *  TCP协议概述
         *  TCP的应用场景
         *  TCP的特点
         *  TCP的报文格式
         *  TCP三次握手
         *  TCP四次挥手
 *  2、UDP协议
 *   *   *  UDP概述
         *  UDP的应用场景
         *  UDP的特点
         *  UDP报文格式
 *  3、协议对比
 *  4、应用层常见协议及端口

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTgxNzQ3Ng_size_16_color_FFFFFF_t_70_pic_center]

# 1、TCP协议 #

### TCP协议概述 ###

传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。

### TCP的应用场景 ###

需要将传输的文件分段传输，建立会话。具体应用场景如下：

*  效率要求相对低，但对准确性要求相对高的场景，因为传输中需要对数据进行确认，重发，排序等操作，效率没有UDP高。
 *  文件传输：FTP\\HTTP对数据的准确性要求高，速度可以相对慢。
 *  发送或接收邮件：POP3\\IMAP\\SMTP对数据准确性要求高，非紧急应用。
 *  远程登陆：TELNET\\SSH对数据准确性有一定要求，有连接概。

### TCP的特点 ###

*  TCP是面向连接的传输协议。
 *  每一条TCP连接只能有2个端口。每一条TCP连接只能是点对点的。
 *  TCP提供可靠通信。
 *  TCP是全双工通信。
 *  面向字节流。

### TCP的报文格式 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTgxNzQ3Ng_size_16_color_FFFFFF_t_70_pic_center 1]

*  源端口：源端口和IP地址的作用是标识报文的返回地址。
 *  目的端口：端口指明接收方计算机上的应用程序接口。
 *  序列号：序号是本报文段发送的数据组的第一个字节的序号。在TCP传送的流中，每一个字节一个序号。一个报文段的序号为300，此报文段数据部分共有100字节，则下一个报文段的序号为400。所以序号确保了TCP传输的有序性。
 *  确认号：即ACK，指明下一个期待收到的字节序号，表明该序号之前的所有数据已经正确无误的收到。确认号只有当ACK标志为1时才有效。比如建立连接时，SYN报文的ACK标志位为0。
 *  数据偏移／首部长度：4位，该字段的值是TCP首部（包括选项）长度除以4。
 *  保留：为将来定义新的用途保留，现在一般置0。
 *  控制位：URG ACK PSH RST SYN FIN，共6个，每一个标志位表示一个控制功能。  
    1.URG：紧急指针标志，为1时表示紧急指针有效，为0则忽略紧急指针。  
    2.ACK：确认序号标志，为1时表示确认号有效，为0表示报文中不含确认信息，忽略确认号字段。  
    3.PSH：push标志，为1表示是带有push标志的数据，指示接收方在接收到该报文段以后，应尽快将这个报文段交给应用程序，而不是在缓冲区排队。  
    4.RST：重置连接标志，用于重置由于主机崩溃或其他原因而出现错误的连接。或者用于拒绝非法的报文段和拒绝连接请求。  
    5.SYN：同步序号，用于建立连接过程，在连接请求中，SYN=1和ACK=0表示该数据段没有使用捎带的确认域，而连接应答捎带一个确认，即SYN=1和ACK=1。  
    6.FIN：finish标志，用于释放连接，为1时表示发送方已经没有数据发送了，即关闭本方数据流。
 *  窗口：滑动窗口大小，用来告知发送端接受端的缓存大小。
 *  校验和：奇偶校验，此校验和是对整个的 TCP 报文段，包括 TCP 头部和 TCP 数据。
 *  紧急指针：只有当 URG 标志置 1 时紧急指针才有效。紧急指针是一个正的偏移量，和顺序号字段中的值相加表示紧急数据最后一个字节的序号。 TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式。

### TCP三次握手 ###

*  客户端发送SYN（SEQ=x）报文给服务器端，进入SYN\_SEND状态。
 *  服务器端收到SYN报文，回应一个SYN （SEQ=y）ACK（ACK=x+1）报文，进入SYN\_RECV状态。
 *  客户端收到服务器端的SYN报文，回应一个ACK（ACK=y+1）报文，进入Established状态。  
    三次握手完成，TCP客户端和服务器端成功地建立连接，可以开始传输数据了。

### TCP四次挥手 ###

*  某个应用进程首先调用close，称该端执行“主动关闭”（active close）。该端的TCP于是发送一个FIN分节，表示数据发送完毕。
 *  接收到这个FIN的对端执行 “被动关闭”（passive close），这个FIN由TCP确认。
 *  一段时间后，接收到这个文件结束符的应用进程将调用close关闭它的套接字。这导致它的TCP也发送一个FIN。
 *  接收这个最终FIN的原发送端TCP（即执行主动关闭的那一端）确认这个FIN。

# 2、UDP协议 #

### UDP概述 ###

User Data Protocol用户数据包协议，是传输层中一种无连接协议。提供面向报文的简单不可靠信息传送服务。UDP在IP报文的协议号是17。UDP不对数据包分组、组装以及不能对数据包进行排序，当报文发送之后，UDP是无法得知其是否安全完整到达的。

### UDP的应用场景 ###

UDP运用在一个数据包就能够完成数据通信，不需要分段，不需要建立会话，不需要流量控制，是不可靠的传输协议。绝大多数UDP应用都不需要可靠机制，甚至可能因为引入可靠机制而降低性能。流媒体、即时多媒体游戏和IP电话就是典型的UDP应用。如果某个应用需要很高的可靠性，那么可以用传输控制协议（即TCP协议）来代替UDP。

### UDP的特点 ###

*  UDP是无连接的，传输数据之前源端和终端不建立连接不需要建立连接。
 *  吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。
 *  UDP支持一对一、一对多、多对一和多对多的交互通信。
 *  UDP是面向报文。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。既不拆分，也不合并，而是保留这些报文的边界，因此，应用程序需要选择合适的报文大小。
 *  UDP信息包只有8个字节，相对于TCP的20个字节信息包而言UDP的额外开销很小。

### UDP报文格式 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTgxNzQ3Ng_size_16_color_FFFFFF_t_70_pic_center 2]  
UDP报头由4个域组成，其中每个域各占用2个字节，具体包括源端口号、目标端口号、数据报长度、校验值。

*  源端口号：发送端口。
 *  目标端口号：接受端口。
 *  数据报长度：保存了UDP首部的长度跟数据长度之和。
 *  校验值：提供可靠的UDP首部和数据。

# 3、协议对比 #

UDP和TCP协议的主要区别是两者在如何实现信息的可靠传递方面不同：

*  TCP 是面向连接的传输控制协议；而UDP 提供了无连接的数据报服务。
 *  TCP 具有高可靠性，确保传输数据的正确性，不出现丢失或乱序；UDP 在传输数据前不建立连接，不对数据报进行检查与修改，无须等待对方的应答，所以会出现分组丢失、重复、乱序，应用程序需要负责传输可靠性方面的所有工作。
 *  UDP 具有较好的实时性，工作效率较 TCP 协议高。UDP 段结构比 TCP 的段结构简单，因此网络开销也小。
 *  TCP 协议可以保证接收端毫无差错地接收到发送端发出的字节流，为应用程序提供可靠的通信服务。对可靠性要求高的通信系统往往使用 TCP 传输数据。

# 4、应用层常见协议及端口 #

<table> 
 <thead> 
  <tr> 
   <th>常见服务</th> 
   <th>协议</th> 
   <th>端口号</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>POP3</td> 
   <td>TCP</td> 
   <td>110</td> 
  </tr> 
  <tr> 
   <td>IMAP</td> 
   <td>TCP</td> 
   <td>143</td> 
  </tr> 
  <tr> 
   <td>SMTP</td> 
   <td>TCP</td> 
   <td>25</td> 
  </tr> 
  <tr> 
   <td>Telnet</td> 
   <td>TCP</td> 
   <td>23</td> 
  </tr> 
  <tr> 
   <td>RDP</td> 
   <td>TCP</td> 
   <td>3389</td> 
  </tr> 
  <tr> 
   <td>PPTP</td> 
   <td>TCP</td> 
   <td>1723</td> 
  </tr> 
  <tr> 
   <td>HTTP</td> 
   <td>TCP</td> 
   <td>80</td> 
  </tr> 
  <tr> 
   <td>HTTPS</td> 
   <td>TCP</td> 
   <td>443</td> 
  </tr> 
  <tr> 
   <td>FTP</td> 
   <td>TCP</td> 
   <td>20/21</td> 
  </tr> 
  <tr> 
   <td>NTP</td> 
   <td>UDP</td> 
   <td>123</td> 
  </tr> 
  <tr> 
   <td>RADIUS</td> 
   <td>UDP</td> 
   <td>1645</td> 
  </tr> 
  <tr> 
   <td>DHCP</td> 
   <td>UDP</td> 
   <td>67</td> 
  </tr> 
  <tr> 
   <td>DNS</td> 
   <td>TCP/UDP</td> 
   <td>53</td> 
  </tr> 
  <tr> 
   <td>SNMP</td> 
   <td>UDP</td> 
   <td>161</td> 
  </tr> 
  <tr> 
   <td>TFTP</td> 
   <td>UDP</td> 
   <td>69</td> 
  </tr> 
  <tr> 
   <td>L2TP</td> 
   <td>UDP</td> 
   <td>1701</td> 
  </tr> 
  <tr> 
   <td>ipsec</td> 
   <td>UDP</td> 
   <td>500</td> 
  </tr> 
 </tbody> 
</table>

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTgxNzQ3Ng_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/70d100912c414bcf976a534c23169236.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTgxNzQ3Ng_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/eacd76ec657a4239b83dd452caa38d7b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTgxNzQ3Ng_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/80486155fe4d4fd8872df1ad75275372.png