传输层协议:TCP,UDP

传输层

端口号:标识了一个主机上进行通信的不同的应用程序;一个端口号标识一个进程,一个端口号只能被一个进程占用,但是一个进程可以绑定多个端口号。
TCP/IP协议使用五元组来标识一个通信(使用netstat -n查看);五元组:“源IP”,“源端口号”,“目的IP”,“目的端口号”,“协议号”
端口号范围划分:0-1023:知名端口号,HTTP(80)/FTP(21)/SSH(22)/TALENT(23)/HTTPS(443)这些广为使用的应用层协议,他们的端口号都是固定的。
cat/etc/services(知名端口号)
1.TCP协议:传输控制协议
6位标志位:URG(紧急指针是否有效)、ACK(确认号是否有效)、PSH(提示接收端应用程序立刻从TCP缓冲区中巴数据读走)、RST(对方要求重新连接,把携带RST标识的称为复位报文段)、SYN(请求建立连接,携带SYN标识的称为同步报文段)、FIN(通知对方,本端要关闭了,携带FIN标识的称为结束报文段)
16位校验和:发送端填充,CRC校验,接收端校验不通过,则认为数据有问题,此处的校验和包含首部和TCP数据部分。
16位紧急指针标识哪部分数据是紧急数据
正常情况下,TCP要经过三次握手建立连接,四次挥手断开连接
主动发起请求的一方就是客户端,被动接收数据的一方是服务端
三次握手:
A:客户端发送SYN包(ACK=j)到服务器(目标主机的TCP层),客户端进入SYN_SEND状态
B:服务端收到SYN包,必须要确认客户的SYN包(ACK=j+1),同时自己发送一个SYN+ACK包,服务器端进入SEND_RCVD
C:客户端收到SYN+ACK包,向服务器发送确认包ACK,发送完双方都进入ESTABLISHED状态。
四次挥手:
D:主动方发送一个FIN(用来关闭主动方到被动方的数据通信),主动方进入FIN_WAIT1状态。
E:被动关闭方收到FIN包后,发送一个ACK给主动方,确认序号为收到序号+1,和SYN一样,一个FIN占一个序号,被动方进入CLOSE_WAIT状态
F:被动方一个FIN,用来关闭被动方到主动方的数据通信,被动方进入LAST_ACK状态
G:主动方收到FIN包,主动方进入TIME_WAIT状态,向被动方发送ACK,确认序号为收到序号+1,双方进入CLOSED状态。

为什么握手是三次,挥手是四次?
两次握手不安全:1)SYN可能会延迟,缺乏状态保护的情况下,服务器端收到一个SYN就会创建一个socket,完整的状态保护要避免对一个客户端创建多个socket。
2)服务短无法通过SYN确认客户端具有数据接收和发送的功能,需要发送SYN再次确认
四次不必要。
被动方接收到FIN后要对其进行ACK回复,不能立即关闭socket,因为用户可能在处理数据,socket接收缓冲区中可能会有数据,需要用户来发送一次确认什么时候关闭socket发送FIN,所以ACK和FIN不能一块发送

半连接队列:
服务器第一次收到客户端的SYN后,就会处于SYN_RCVD状态,此时双方还没有完全建立起连接,服务器会把这种状态下的请求放在一个队列中,这个队列称为半连接队列。
全连接队列:
已经完成三次握手,后面的请求会放在全连接队列中。
三次握手在最后一次握手的时候可以携带数据,因为前两次握手如果受到攻击就会让服务器更容易受到攻击,而第三次握手的时候已经确定了双方具有收发数据的能力。
服务端的资源分配是在二次握手时进行分配的,客户端的资源是在完成三次握手时分配的。

主动关闭方TIME_WAIT的作用:
如果主动方直接进入CLOSED状态,如果主动关闭方以相同的地址信息重启,1)收到被动关闭方发送的FIN请求,直接对新连接产生影响。2)发送SYN请求,而等待的是ACK,因为状态不对而对新连接产生影响。
因此主动关闭方需要等待一段时间(2个MSL,MSL是报文最大生命周期,一个MSL大概是30秒,是可配置的)若是对方重发FIN请求,可以对其进行再次确认回复再关闭
等待两个msl时间是因为每个报文都有其生命周期,为了让网络中延迟的报文(后续重传的fin和ack)都消失在网络中,不会对后续新连接造成影响
大量TIME_WAIT解决方案:1)调整MSL时间;2)设置套接字选项(地址复用)

TCP的可靠传输:
面向连接,确认应答机制(对每一条数据项发送方进行确认回复),超时重传机制(发送数据后等待一段时间(200ms)若是没有回复就认为数据丢失,进行数据重传,协议字段中的序号+确认号保证了有序地向应用层交付;协议字段中的校验和能校验收到的数据和发送的数据是否相同,不同则发送重传请求,否则确认回复。
TCP为了保证可靠传输,牺牲了部分性能,有些性能的牺牲是不必要的,比如ACK丢失导致的重传。
TCP采用了几种机制来避免不必要的损失:
1)滑动窗口机制(双方在进行数据传输过程中协商窗口大小)
一发一收的方式性能比较低,可以一次发送多条数据,其实是将多个段的等待时间重叠在一起了。
窗口大小是指无需等待确认应答而可以继续发送数据的最大值,在发送窗口大小可容纳的数据时,不需要等待任何ACK,直接发送,收到第一个ACK后,滑动窗口向后移动,然后继续发送。
操作系统内核为了维护这个窗口需要开辟【发送缓冲区】来记录当前哪些数据还没有应答,只有确认应答过的数据才能从缓冲区删掉。
窗口越大,网络吞吐量越高。
A:流量控制:根据接收端的处理能力来决定发送端的发送速度。
通过协议字段中的窗口大小(不会大于接收方的接收缓冲区中剩余空间大小)字段控制发送方发送的数据大小;避免因为发送过快而接收方数据处理过慢到时接收缓冲区数据放满后,
大量数据丢失重传降低的性能;窗口大小在每次进行确认回复的时候都会进行重新协商。
每一条确认回复中的确认序号都要保证之前的数据都已经完全收到;避免因为ack丢失导致的数据重传,比如,没有收到第一条回复,但是收到第二条回复,认为第一条和第二条都已经正确传输。
B:快速重传机制
收到了第二条数据但是没有收到第一条,则初步认为第一条数据丢失,则初步认为第一条数据丢失,则立即发送第一条数据的重传请求,并且连续发送三次。
当发送方连续收到三次重传请求的时候,就不需要进行超时等待直接对这条数据进行重传。
C:拥塞控制
网络通信开始时,并不会直接发送窗口大小的数据,而是以一种慢启动,快增长的形式进行数据传输,
起到一个网络探测的作用,避免开始通信时因为网络状况不好导致的发送数据越多,丢失数据越多的重传性能损失。
在快增长的过程中,若出现丢包,则初始化拥塞窗口大小,重新开始探测网络状况。
2)延迟应答机制:如果接受数据的主机立刻返回ACK应答,则这时候返回的窗口可能比较小。
接收方接收数据若是立即回复,则窗口大小会降低,会导致传输速率降低,因此接收方接收数据后,并不会立即回复,而延迟一会(不超过500ms)
在这期间,用户可能将数据从接收缓冲区取出,可以尽可能保证窗口大小,保证速度不会降低;
3)捎带应答机制:将ACK和服务器回复的数据一块发送给客户端
每次接收方对发送的数据进行确认回复,若是单独发送一个数据报(仅仅包含一个tcp报头)
是不划算的,解决方案就是将要进行的确认回复和即将要发送的数据合并到一起发送,
就可以省略一个tcp报头的发送,减少网络中不必要的流量信息。

面向字节流:数据不会直接发送,而是放在数据缓冲区中,操作系统找个合适的时间将合适大小的数据以二进制字节流的形式发送出去。接收方接收数据可以选择一次性接收所有数据,也可以一次接收一部分数据
粘包问题:其中的包指的是应用层的数据包
粘包特性:也就是tcp传输的数据在发送缓冲区或者接收缓冲区中堆积,因为TCP数据收发的灵活性,
导致有可能多条数据当做一条数据接收(两条数据的粘连)也就是tcp传输的数据在发送缓冲区或者接收缓冲区中堆积。
粘包的主要原因:TCP在传输层,对数据的格式没有明确的边界区分,因此会造成数据的粘连。
粘包是TCP在传输层,对数据边界不敏感,因此需要用户在应用层进行数据边界管理。
1)特殊字符间隔;局限性:传输的数据有特殊字符,就需要编码,接收时候就要解码。
2)定长数据:局限性,数据的长度过大或过小
3)不定长数据:在应用层协议头中声明数据长度***

基于TCP应用层协议:HTTP/HTTPS/SSH/Talent/FTP/SMTP(简单邮件传输协议,基于文本的协议)
2.UDP协议:无连接(知道对端的端口号,IP就能直接进行传输,不需要建立连接)、不可靠(没有确认应答机制,没有重传机制,如果因为网络故障数据没有发送给对方,UDP协议也不会给应用层返回任何错误信息),面向数据报(不能够灵活地控制读写数据的次数和数量)。
应用层交付给UDP的数据,UDP原样发送,不会合并也不会拆分。
UDP的socket可读可写,是全双工。
UDP每次直接传输的报文大小是有长度限制的64k;若是数据过长,需要用户在应用层进行数分包(但是UDP不保证有序),所以还需要用户在应用层进行数据包序管理。
怎么用UDP实现可靠传输?
1)引入序列号,保证数据顺序;2)引入确认应答,保证对端收到了数据;3)引入超时重传,如果隔一段时间没有应答,就重发数据。
基于UDP的应用层协议:NFS(网络文件系统)、TFTP(简单文件传输协议)、DHCP(动态主机配置协议)、BOOTP(启动协议,用于无盘设备启动)、DNS(域名解析器协议)

相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页