关于TCP/IP协议

Posted 2020-08-12 珍真小心

TCP的特点：

TCP是面向连接的传输层协议

TCP的传输是可靠传输

TCP是全双工的通信

TCP的连接是点对点的传输

 

TCP和UDP的区别

• tcp是面向连接的，两台主机的通信之前必须通过三次握手建立连接；而UDP是不需要建立连接的
• TCP提供的是可靠传输，TCP通过确认和重传机制来保证传输的质量，而UDP没有。所以TCP没有丢包而UDP有丢包的现象
• TCP提供了拥塞控制和和滑动窗口等来保证传输的质量，UDP没有
• TCP只能是点对点的传输，UDP可以支持一对一、一对多、和多对多的通信
• TCP适用于传输大量的数据对可靠性要求高的环境，UDP适用于追求效率和对可靠性不高的环境
• TCP的头部最小为20个字节，UDP的头部为8个字节
• TCP面向的是字节流服务，UDP面向的是报文服务

 

TCP报文结构

源端口和目的端口各占2个字节

序号占4个字节

确认号占4个字节

数据偏移、保留和窗口共同占有4个字节

检验和、紧急指针共同占有4个字节

以上的这些共同构成TCP头部的固定首部

再加上可选的选项和填充构成TCP的首部

TCP报文由TCP首部和传输的数据组成

 

TCP的三次握手

第一次握手：客户端发送syn（syn=x）请求包到服务器，进入syn_send状态

第二次握手：服务器收到客户端发来的syn包，确认客户的syn包（ack=syn+1），然后再发送请求包syn（syn= y）到客户端，所以就发送的是ACK+SYN包给客户端，进入syn_recv状态

第三次握手：客户端接收到服务器发来的ack+syn包，确认服务器的syn包（ack = syn+ 1），发送ack包，进入established状态

三次握手建立连接之后，才开始发送数据，若没有断开连接，则连接将会一直进行下去

 

若TCP只进行两次握手不进行三次握手可以吗？

不可以，采用三次握手是为了防止失效的连接请求报文段突然又发送给服务器，产生错误。

如下场景：若客户端发送了一个请求给服务器，但是因为网络时延等问题请求包迟迟没有到达服务器，过了一段时间后，客户端重新发送了一个请求，服务器接收到了发送确认并建立了连接。在通信之后，断开连接。但是原来第一个请求包又重新发给了服务器，服务器收到了就发送给客户端一个确认，但是实际上客户端并没有发送请求，所以不会理会。这样服务器就一直等待客户端发送数据，造成服务器资源浪费。

 

TCP的四次挥手

第一次挥手：客户端发送一个fin（fin = x）包，告诉服务器不会再发送数据到服务器了，但此时客户端还是可以继续发送和接收数据

第二次挥手：服务器收到客户端发来的断开连接的请求，确认发送一个ack包（ack= x+1），此时客户端只能接收数据不能发送数据

第三次挥手：当服务器发送完数据之后，就会发送一个断开连接的请求fin包（fin = y），告诉客户端“我的数据也发送完了”

第四次挥手：当客户端收到服务器发来的断开连接的请求时，确认发送一个ack包（ack = y+1），这时双方都断开连接，不能再收发数据

 

TCP流量控制：

　　TCP的流量控制就是指点对点通信量的控制，是端到端的问题。要做的就是限制发送端发送数据的速率，以便发送端来的及接收。TCP流量控制是通过滑动窗口来实现的，发送方的发送窗口不能超过接收方的窗口。TCP的窗口单位是字节而不是报文段。

　　大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值ack，rwnd表示窗口的大小，Data表示报文段的长度。设每一个报文段为100字节长，而数据报文段序号的初始值设为1，如下图：

　　假如，B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwind=400的报文段，然而这个报文段在传送中丢失了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。这样就死锁了。为了解决这种死锁状态，TCP为每个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。

TCP拥塞控制：

拥塞：即对资源的需求超过了可用的资源。如果网络中许多资源同时供应不足，网络的性能就会下降，整个网络的吞吐量就会随着负荷的增大而下降。

拥塞控制：防止较多的数据注入网络中，这样可以使网络中的路由器或链路不至于过载。

拥塞控制所要做的都有一个前提：网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络传输性能有关的所有因素。

几种拥塞控制的方法：

慢开始、拥塞避免、快重传、快恢复

慢开始和拥塞控制

发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口可能小于拥塞窗口。

       慢开始算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。

       这里用报文段的个数的拥塞窗口大小举例说明慢开始算法，实时拥塞窗口大小是以字节为单位的。如下图：

       当然收到单个确认但此确认多个数据报的时候就加相应的数值。所以一次传输轮次之后拥塞窗口就加倍。这就是乘法增长，和后面的拥塞避免算法的加法增长比较。

       为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下：

　　　　当cwnd<ssthresh时，使用慢开始算法。

　　　　当cwnd>ssthresh时，改用拥塞避免算法。

　　　　当cwnd=ssthresh时，慢开始与拥塞避免算法任意。

       拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口按线性规律缓慢增长。

       无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理），就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法。如下图：

      再次提醒这里只是为了讨论方便而将拥塞窗口大小的单位改为数据报的个数，实际上应当是字节。

快重传和快恢复

 快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。如下图：

快重传配合使用的还有快恢复算法，有以下两个要点:

①当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢开始算法。

②考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。如下图：

 

TCP对应的协议和UDP对应的协议
TCP对应的协议：
（1） FTP：定义了文件传输协议，使用21端口。
（2） Telnet：一种用于远程登陆的端口，使用23端口，用户可以以自己的身份远程连接到计算机上，可提供基于DOS模式下的通信服务。
（3） SMTP：邮件传送协议，用于发送邮件。服务器开放的是25号端口。
（4） POP3：它是和SMTP对应，POP3用于接收邮件。POP3协议所用的是110端口。
（5）HTTP：是从Web服务器传输超文本到本地浏览器的传送协议。
UDP对应的协议：
（1） DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。
（2） SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
（3） TFTP(Trival File Tran敏感词er Protocal)，简单文件传输协议，该协议在熟知端口69上使用UDP服务。

IP地址分类：

A类：1.0.0.0--126.255.255.255

B类：128.0.0.0--191.255.255.255

C类：192.0.0.0--223.255.255.255

D类：多播地址

E类：保留地址

特殊的IP地址：

• 0.0.0.0：已经不是一个真正意义上的IP地址。它表示的是这样一个集合：所有不清楚的主机和目的网络。这里的“不清楚”是指在本机的路由表里没有特定条目指明如何到达。如果在网络设置中设置了缺省网关,那么系统会自动产生一个目的地址为0.0.0.0的缺省路由.对本机来说,它就是一个“收容所”,所有不认识的“三无”人员,一 律送进去。

• 255.255.255.255： 限制广播地址，对本机来说,这个地址指本网段内(同一广播域)的所有主机。这个地址不能被路由器转发。

• 127.0.0.1：本机地址主要用于测试。这样一个地址,是不能把它发到网络接口的。

IP地址与子网掩码相与得到网络号