TCP/IP模型中,自顶向下分别为应用层,传输层,网络层,数据链路层、物理层。
应用层典型的协议有:HTTP,HTTPS,FTP协议,SMTP协议,没有典型设备,主要负责产生网络数据,网络数据来源于进程。
传输层典型的协议有:TCP,UDP协议,没有典型设备,主要负责端与端之间的传输,端就指的是端口
网络层典型的协议有:IP协议,ICMP协议,典型的设备是路由器,主要负责路由选择,为网络数据选择一条合适的路由。
数据链路层典型的协议有:以太网协议,典型的设备是交换机,主要负责相邻设备之间的传输。负责将数据从A节点传输到B节点。
物理层典型的协议有:以太网协议,典型的设备是集线器和中继器,主要负责将光电信号转换为二进制数据,或者将二进制数据转换为光电信号。
要从三个角度来分析:
1.数据包名称
2.双方的状态变化
3.包序的变化
要从三个角度来分析:
1.数据包名称
2.双方的状态变化
3.包序的变化
不行,从两个角度说明:
1.两次握手之后,站到客户端的角度,认为连接已经建立,但是站到服务端的角度,SYN_RECV状态并没有转换为ESTBASLISH状态,认为连接没有建立
2.只能证明服务端的接收和发送能力是正常的,也能证明客户端的发送能力是正常的,但是不能证明客户端的接收能力也正常
1.纯的ACK数据包是不消耗TCP序号的
2.ACK+SYN,ACK+FIN这类没有包含应用层数据的数据包,消耗1个序号
3.携带应用层数据的数据包,会将应用层数据逐字节进行标记,其消耗的序号为应用层数据的大小
可以,但是只能在第三次握手的时候携带数据
如果在第一次和第二次握手的时候携带了数据,如果有人恶意用大量数据访问服务端,就会导致服务端需要消耗大量资源去保存这些数据,是不合理的。
但是在第三次握手的时候,客户端已经认为连接建立了,那么发送数据也是合理的,但是日常在第三次握手的时候就发送数据的场景不多见
可以
两次挥手之后,被动断开连接方可以给主动断开连接方发生数据(这个过程发生在两次挥手之后,第三次挥手之前)
如果是服务端等待2MSL,那么意味着是服务端先断开连接的。
MSL:报文最大生成时间,报文在网络上存在的最长时间
总结:为了防止主动断开连接方发送的ACK丢失,被动断开连接方会重传FIN报文
详细阐述:主动断开连接方接收到被动断开连接方发送的FIN报文后,变为了TIME_WAIT状态,然后需要等待2MSL,在2MSL的时间内收到被动断开连接方发送的ACK报文后才能变为CLOSED状态,就是由于存在发送的ACK报文在网络中丢失,那么被动断开连接方会重传FIN报文,因此2MSL的时间=自己发送的ACK报文的MSL + 重传FIN报文的MSL。
listen函数有两个参数
listen(int socket, int backlog)
socket表示的是侦听套接字,是socket函数的返回值,backlog是已完成连接队列的大小
因为服务端会将连接分为未完成连接队列(中放的是正在进行三次握手的连接),已完成连接队列(已经完成三次握手的连接),而未完成连接队列中已经完成的连接会被放入已完成连接队列中
不进行accept的话,最多可以完成backlog+1个连接
1.服务端完成TCP连接的个数是取决于操作系统的上限
2.操作系统会规定一个值,open files来规定一个进程最多可以打开多少个文件描述符
3.我的机器中看到的是1024,意味着最多能够打开1024个文件描述符,意味着服务端最多可以完成的TCP连接数为1024-3-1,3是一个进程默认的标准输入,标准输出,标准错误,1表示侦听套接字
4.当然open files的值可以通过ulimit -n来进行修改
不一定,初始序号是动态的
1.初始化序号可以看作是32位计数器,这样选择序号的目的在于防止被网络延迟的分组后续又被传输,从而导致错误的解释
2.三次握手中,客户端和服务端互相交换初始化序号,之后的数据包就按照约定的初始化序号向下使用。如果固定为0,则会导致网络攻击者很容易模拟TCP数据包,来攻击服务端。
MSS:TCP最大传输报文长度,意思是TCP将数据递交给网络层的数据大小。
在三次握手时,双方就MSS大小进行协商,取其较小值。
协商的目的是:
1.如果没有进行协商,如果传递的数据包过大,递交给网络层之后,IP协议会进行分片,而IP协议是不可靠的,如果发生一个分片丢失,那么TCP会认为整个数据包丢失,会重传整个TCP数据包
2.如果TCP交给网络层的数据大小满足MSS,那么IP协议不会进行分片传输
close_wait状态只会出现在四次挥手的被动断开连接方,也就意味着服务端是被动断开连接方
只有当主动断开连接方发送给被动断开连接方FIN报文之后,被动断开连接方才会从estbalish状态转换到close_wait状态,而进一步转换到last_ack状态需要被动断开连接方调用close函数,进行关闭的操作。
如果服务端出现大量close_wait状态,说明服务端没有调用close函数,进一步的原因可能是:
1.close函数被阻塞
2.执行close函数的线程,在执行到close之前有非常耗时的操作
3.根据实际情况看还有其他的可能导致没有调用到close函数
会导致占用大量的服务端资源
按照TCP包头中32位序号来看,维护的序号范围是0–>4294967295
当超出这个序号的最大范围后,就会发生“序号回绕”,也就是从最大值回到0开始继续向后走。
用无符号char类型来举例:
0-255的范围
如果当前序号在254,接下来有一个4字节的数据包,TCP维护的序号就是255->0->1->2,接下来的序号就是3.
当发送方发送一个数据包,接收方需要进行接收确认,返回ack来确认收到了这个数据包
而确认的本质是在确认序号。而序号本质上就是数据,因为TCP对应用层的每个字节都进行了编号
超时重传时间(RTO)是不固定的,是随着报文往返时间(RTT)进行动态变化的。
简单的说:RTT时间小,说明网络情况好,则RTO变小,RTT时间长,说明网络情况查,则RTO变大
快重传是为了在没有触发超时重传的时候,就触发发送方传递了数据。
本质上是为了提高传输效率的
做法:当发送方连续收到三次同样的确认数据包,就会触发快重传,立即发送丢失的数据包。
是存在效率问题的:主要问题就是当序号为A的数据包已经后续的几个数据包都丢失之后,那么虽然对当前的数据包进行了快重传,但是后续丢失的数据包也需要再次等3次同样的数据包才能触发快重传,这样会导致效率较低。
解决办法 SACK,在TCP头部的40字节选项中,描述接收方收到了哪些数据包,那么在发送方来说,就会知道哪些数据包丢失了,就会触发快重传进行发送。
TCP的缓冲区是操作系统内核中的一块空间。
1.发送缓冲区和接收缓冲区都是环形队列
2.调用send函数,进程产生的数据会被放到发送缓冲区中,TCP会择机将缓冲区的数据发送;
3.调用recv函数,会从TCP的接收缓冲区中将数据拷贝到准备好的空间