linux网络tcpudp详解,网络管理 tcp/udp详解 （传输层）

简介：

TCP和UDP的区别

TCP是面向连接的传输控制协议，而UDP提供了无连接的数据报服务。

TCP具有高可靠性，确保传输数据的正确性，不出现丢失或乱序；UDP在传输数据前不建立连接，不对数据报进行检查与修改，无须等待对方的应答，所以会出现分组丢失、重复、乱序，应用程序需要负责传输可靠性方面的所有工作；

UDP具有较好的实时性，工作效率较TCP协议高；

UDP段结构比TCP的段结构简单，因此网络开销也小。

传输层主要采用的两种通信方式，一种是提供可靠传输的TCP协议，一种是提供不可靠传输的UDP协议

软件端口是应用层的各种协议进程与运输实体件键兴层间交互的一种地址

计算机中的端口分类

计算机中的端口一般分为两种

一种是服务端使用的端口

服务端的端口也分为两小类，一类叫做系统端口或特权端口：0~1023

应用程序         http   https   ftp    tftp   smtp   pop3   imap   telnet   ssh

系统端口号     80      443     21     69      25        110     143     23        22

另一类叫做用户端口或者注册端口 1024-49151   (使用这一类型端口需要注册)

另一大类型为动态端口，49152~65535，在客户端运行时才会动态选择，也叫短暂端口号

TCP和UDP的区别：

1，tcp面向连接，udp非面向连接。—tcp提供面向连接的服务，在进行报文交互传输前需进行3次握手的连接建立，在数据交互完成时需要进行4次挥手的断开连接。udp在传输udp用户数据报的时候不需要提前建立连接，采用直接发送的方式。

2，tcp为可靠的交互，udp为不可靠的交互。–tcp提供重传和按序号传送的以及流量控制的功能，udp只是进最大的努力交付。

3，tcp拆分传输，udp整个传输。–tcp是面向字节流的，它把数据看作一连串无结构的字节流，它会对数据进行分拆包装，udp对应用层交付下来的报文不拆分也不组合，直接发送。一次发送一个报文。

4.通信方式不同 –tcp支持一对一的交流方式，udp支持一对一，一对多，多对多，多对一的交流方式。

5，tcp有发送窗口等待的机制，可以实现流量控制，而udp没有发送窗口的机制，它不能进行拥塞控制和流量控制。

6.检验方式不一样，udp计算检验是把首部和数据部分一起检验，tcp只是检验IP数据报的首部

UDP的报文首部：

首部由8个字节四个部分组成，每个部分由2个字节

1，源端口：在需要交互方回复的时候选用，不需要回复使用0

2.目的端口：在终点交付报文的时候必须使用。

3，长度：udp用户数据报的长度，最小为8

4，检验和：检测udp数据报在传输中是否有错误，有错就将其丢弃。(在计算检验和时，要在udp用户数据报之前添加12个字节的伪首部，伪首部即不下传递也不向上递交，作用仅为计算检验和)

TCP首部

1：源端口和目的端口：各占两个字节。

2.序号：占4个字节，也叫报文段序号，TCP传输的每一个字节都按顺序编号。序号指的是本报文段发送的数据 的第一个字节的序号

3.确认号：占4个字节，表示期望收到对方下一个报文段的第一个数据字节的序号(确认序号减去序号等于本段传输的报文长度，确认号表示在这个序号的前一个数据之前的信息全部正常接收)

4，数据偏移：占4个字节，指出TCP报文段的数据起始处距离tcp报文段的起始有多远。

5，保留位：占6个字节 (一般不使用)

6，紧急指针位(URG)当urg=0时，表示紧急指针无效  当urg=1时表示紧急指针有效，告诉系统这个报文段中有紧急数据，应当尽快传输。紧急数据插入本报文数据的最前面，紧急指针指出晋级数据的末尾在报文段中的位置。

7，确认ack，当ack=1，确认号字段才有效。当ack=0时确认号无效。tcp规定在建立连接之后所传输的报文段都必须把ack设置为1

8.推送psh，在接收方tcp收到psh=1的报文段，就尽快交付给接收应用进程而不是在得到缓冲区都填满之后在向上交付

9，复位rst，当rst=1，标明tcp有严重的错误，必须释放连接，重新建立传输连接。rst=1还可以用来拒绝一个非法的报文段或者拒绝打开一个连接

10，同步syn，当syn=1，ack=0，标明这是个连接请求报文段，对方如果同意建立连接，在响应报文段中syn=1,ack=1.

11.终止fin，释放一个连接，fin=1,表示报文段的发送方的数据已经发送完成，请求释放连接。

12.窗口：占2个字节，存放的是数据是字节为单位的窗口值告诉对方，本报文段首部中的确认号算起，接收方目前允许对方发送的数据量。这是让发送方设置发送窗口的依据

13.检验和，占2个字节

TCP的可靠原理

1，停止等待协议

发送方发送之后等待接收方的确认报文，在继续发送，如果出现发送丢失或者确认报文丢失，超时计时器到期，进行超时重传。如果编号不对，也会进行重传的活动。

(使用确认和重传机制，可以在不可靠的传输网络上进行可靠传输)

2,连续arp协议：

使用了滑动窗口的机制。

累积确认的方式，对按序到达的一个分组发送确认，如果分组的数据段丢失只会确认前接收的

3.流量控制：发送方不要太快，让接受方来得及接收。(利用滑动窗口机制实现对发制)

接收方额主机进行了三次流量控制，而且ACK=1时确认字段才有意义

TCP拥塞控制

1,基本概念

拥塞：即在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可承受能力，网络就会变坏

拥塞控制：防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不至于过载。要实现拥塞控制都有一个前提：网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程。涉及到所有的主机，路由器，以及与降低网络传输信能有关的所有因素。

流量控制：指点对点通信量的控制，是端到端正的问题。流量控制所要做的就是抑制发送端发送属的速率。使接收端来得及接收。

拥塞控制代价：需要获得网络内部流量的分布的信息。在实现拥塞控制之前。还需要在结点之间交换信息和各种命令，以便选择控制的策略和实施控制。这样就产生了额外的开销。拥塞控制还需要将一些资源分配给各个用户单独使用，使得网络资源不能更好的实现共享。

2，拥塞控制的办法

慢启动(slow start)        拥塞避免(congestion avoidance )    快速重传(fast retransmit)      快速恢复(fast recovery)

慢启动和拥塞避免

1.发送方维持一个拥塞窗口cwnd的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。

2.发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减少一些，以减少注入到网络中的分组数。

3.慢启动算法：当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此，较好的办法是先探测下，即由小到大逐渐增大发送窗口，也就说，由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文段时，先把拥塞窗口cwnd设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口cwnd，可以使分组注入到网络的速率更加合理。

拥塞避免算法：让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。无论慢启动开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞(其根据就是没有收到确认)，就要把慢启动门限ssthresh设置为出现拥塞时的发送方窗口值的一半(但不能小于2)。然后把拥塞窗口cwnd重新设置为1，执行慢启动算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

快速重传和快速恢复

如果发送方设置了超时计时器时限已到但还没有收到确认，那么很可能是网络出现了拥塞，致使报文段在网络中的某处被丢弃。这时，TCP马上把拥塞窗口cwnd减少到1，并执行慢启动算法，同时把慢启动门限值ssthresh减半。这是不使用快速重传的情况。

快速重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有达到对方)而不要等到自己发送数据时才进行捎带确认。

TCP协议的三次握手

1.由客户端发起tcp请求，SYN=1，seq=x，从而从CLOSED状态转变成SYNSEND状态，准备接受服务器的响应；

2.服务器收到SYN=1的包后回应一个SYN=1，ACK=1的包表示确认，其中seq=y，确认号为x+1表示收到第一次客户端的x包，服务器的状态从LISTEN转换成SYNRCVD，准备接受客户端的下一个确认包；

3.

客户端收到服务器的响应，从而回复一个ACK=1确认包，seq=x+1表示发送自己的下一个包，ack=y+1表示收到了服务器的y包；

客户端发出确认包后从SYNSEND状态切换到ESTABLISHED(已连接状态)；服务器收到ESTABLISHED(已连接状态)，接下来就可以愉快的通信了。

TCP协议的四次挥手

1，A主机发起FIN=1表示断开请求包，seq=u自己的数据包序号，发出FIN包后立即从ESTABLISHED状态转换为FIN-WAIT-1状态，等待服务器的确认；

2，B主机收到FIN=1的包后，回应一条ACK=1的包，表示自己已经收到客户段的分手请求，从而转换为CLOSE-WAIT状态；客户端收到ACK=1的包后从FIN-WAIT-1状态转换为FIN-WAIT-2状态，继续等待服务器的同意请求；

3.B主机器继续发出FIN=1，ACK=1表示服务器同意分手，从而由CLOSE-WAIT状态切换到LAST-ACK状态，等待客户端的最后一次确认请求；

4.A主机收到FIN=1的包后再次发出一个最后的ACK=1确认包，从而转换成TIME-WAIT状态，等待2个MSL(一个包从客户端到服务器的时间为一个MSL时间)时间，确保服务器最后的包全部接受后转换成CLOSED状态；服务器收到最后的ACK=1包后也转换为CLOSED状态。

本文来自投稿，不代表Linux运维部落立场，如若转载，请注明出处：http://www.178linux.com/97322