中数据传输2.1浏览器中输入一个url的执行流程2.2数据在网络中是的传输流程

3三次握手和四次挥手3.1三次握手3.1.1洪范攻击3.1.2为什么需要三次握手

3.2四次挥手3.2.1为什么需要time-wait3.2.2time-wait举例

4UDP协议

在最初的网络中是借鉴于这个OSI七层网络模型而在实际开发应用中更多的还是使用这个TCP/IP模型分别是

相较于OSI模型TCP/IP模型是将会话层和表示层都结合到了应用层里面

Transmission

看到第一个单词传输因此得知这个TCP是在这个传输层的IP的缩写是

Internet

。

如下图应用层中有HTTPTelnet、DNS等协议传输层中包含TCP、UDP协议网络层中包含

TCP是一个可靠连接的一个协议需要通过三次握手建立连接有点类似于两台电话必须接通才能通话。

绝大多数场景下还是通过tcp协议完成的因为该协议相对稳定可靠需要等建立连接之后才能传输数据并且在传输数据时可以通过一定的限流方式进行流量控制从而保证数据传输的可靠性。

UDP是一个面向无连接的协议类似于商家和快递商家不关心用户能不能接收到不需要和用户建立直接关系。

如在实际开发中视频语言等都是通过UDP实现的允许部分数据丢失。

如虎牙斗鱼这些有对应的清晰度通过不同的清晰度决定每次传输数据的大小清晰度越小即使丢包也是允许的

2网络中数据传输

url被称为统一资源定位符一个完整的url都会包含这四部分分别是协议、域名、路径和资源。

当在浏览器中输入一个url时如在浏览器中输入www.baidu.com其内部会执行的流程如下

首先是域名解析就是将网址解析成具体的ip。

如果不是第一次访问这个网址那么正常会在host文件中保存对应的ip那么就可以直接通过本地的host文件解析如果是第一次访问这个网址那么本地host文件中不存在就需要去本地的DNS服务器查找没有再去root根DNS服务器中获取再获取到这个具体的ip之后通过三次握手的方式与对方建立TCP的可靠连接建立连接成功之后再向服务器发送一个http的请求服务器接收到请求之后服务器会处理相关请求随后服务器会将响应结果返回给客户端随后通过四次挥手断开连接浏览器接收到响应之后对响应的内容进行解析浏览器将解析的内容渲染如cssjs等最后进行布局展示

在网络通信中客户端A需要向客户端B发送数据也是需要通过tcp/ip

首先数据会先经过应用层然后携带一个应用层的头部此时为数据包随后继续经过传输层由于是TCP协议因此继续携带一个TCP的头部此时为数据段随后继续经过ip层因此继续携带一个IP层的头部此时为数据报随后到达链路层最后将数据封装成以太网数据帧随后通过以太网电缆传输到目标ip

在通过电缆接收到数据之后会先经过数据链路层层层解析从下往上依次解析先经过链路层随后网络层随后传输层再到应用层全部解析完成之后再返回给客户端

3三次握手和四次挥手

在tcp建立连接时需要通过三次握手来实现连接从而实现这种稳定可靠性其流程如下

首先客户端会向服务端发送一个SYN1的一个报文标志并且设置一个seq_no的字段值为10000此时客户端进入一个

SYN_SENT

的状态服务端在接收到这个请求之后会对客户端进行一个响应也会发送一个SYN1的报文并且设置一个ACK1的标志位同时会返回一个ack_no回应客户端的seq_no值为客户端seq_no的值1最后还会设置一个seq_no的值其值为30000。

此时服务端进入一个SYN_REVD的状态客户端在接收到服务端的响应之后客户端需要给服务端一个响应告诉服务端客户端接收到这个响应了。

会继续返回一个SYN1的报文并且只需要返回一个ack_no其值为服务端seq_no的值1最后服务端和客户端的状态都变为

ESTABLEISHED

三次握手主要的原因是为了建立可靠连接在连接过程中客户端的seq序列号需要服务端的ack序列号应答服务端的seq序列号也需要客户端的ack序列号应答保证可靠性如出现丢包重传的的话那么可以直接根据具体的seq序列号进行重传即可。

主要是通过超时重传机制

应答确认机制

最后一次握手是为了告知服务端客户端确实收到了服务端的响应对于响应syn_no的seq_no的值至于要加多少取决于接收了多个包即取决于SYN的值的大小如果接收了3个包且seq_no的值为10000那么响应的ack_no的值则为10003

3.1.1洪范攻击

SYN洪范攻击的定义如下就是通过网络所在的端口发送大量伪造原地址的攻击报文发送到服务端造成服务端上面的半开连接队列被占满从而阻止其他用户进行访问。

就是利用伪造的ip地址向服务端发出第一次握手而tcp连接为了维护三次握手就会响应这个伪造ip的请求然而服务端这边一直在等客户端的响应即第三次握手如果伪造服务端一直不响应随着伪造ip请求的增多那么服务端的资源会被耗尽。

该方式属于一种ddos的攻击可以通过加防火墙等避免设置定时任务去移除无法响应的请求。

在三次握手中会存在大量的客户端去连接服务端服务端会将不能及时响应的客户端的请求先存放在一个队列中。

那么洪范攻击就会利用这个特性从客户端发送一个伪造的数据报文到服务端服务器会为了保证三次握手就会对这个伪造数据的服务器做出响应由于攻击者的ip是伪造的那么服务器这边的响应就一直到达不了伪造者客户端的ip并且接收不到客户端的第三次响应导致该次连接一直不被释放。

那么伪造多个ip去请求服务端的话那么会造成大量的连接处于不被释放状态从而让这个队列占满导致整个服务器处于瘫痪的状态。

无效连接监控释放就是给一个监听事件对队列中要响应的请求进行监听如果在一定的时间内还没有成功的建立三次握手那么就可以直接将该次请求释放清理掉延缓TCP分配方法

就是在分配tcp的时候在三次握手建立成功之后再来分配tcp开启防火墙

通过防火墙来确认这个客户端ip地址的有效性只有这个ip地址是有效的才与客户端建立连接

3.1.2为什么需要三次握手

上面讲解了三次握手的过程以及三次握手的缺陷然而在tcp协议中为什么建立连接需要三次握手呢其主要原因如下在建立连接过程中双方都会发送一个序列号这样就可以知道发送报文的起始的序列号和最终的序列号从而通过序列号的值知道有哪些报文通过差值确认报文的个数当服务端接收的报文的个数小于差值时就通过序列号确定哪个报文被丢失就会进行重传的操作从而来保证该协议的可靠性

如在服务端给客户端发送建立连接时seq_no的值设置成10000SYN的值设置成3但是服务端这边返回ack_no的值为10002此时差值为2表示只收到两个数据包但是SYN的值为3表示发送了3个数据包故而得知少了一个服务端少接收了一个数据包那么服务端这边就会进行重发的操作。

服务端响应客户端也会发一个seq_no的序列号给客户端然后客户端回应服务端一个ack_no其本质也是一样通过差值和SYN的值进行比较查看是否出现丢包的情况。

3.2四次挥手

当tcp连接断开时其底层也是通过四次挥手的方式来断开连接。

与建立连接的三次握手不一样三次握手是固定的从客户端发起握手的请求但是四次挥手不一样挥手是客户端和服务端都可以发起断开连接的请求。

四次挥手的流程如下(以客户端发起断开请求为例)

首先客户端发起断开连接的请求此时会向服务端发送一个FIN的标志并且会设置序列号seq_no假设此时FIN的值为seq_no的值为8888此时客户端处于FIN_WAIT_1的状态服务端接收到请求之后服务端会先响应一个接收到该请求的响应会往服务端发送一个ACK确认的标志同时返回一个ack_no的值改值为接收到的序列号FIN传过来的包的数量如此时为8889此时服务端处于close_wait的状态一段时间之后服务端会向客户端再次发送一次报文也会设置一个FIN的值和一个seq_no的值如设置一个FIN1seq_no

8890此时服务器端会处于LAST_WAIT的状态客户端在收到服务端发送的第二次报文之后会再向服务端发送一个报文设置ACK1的确认标志并且设置一个ack_no8891的值此时客户端处于TIME_WAITING的状态最后服务端接收到响应报文之后服务端会处于一个CLOSED的状态

3.2.1为什么需要time-wait

在上图中可知在客户端第二次向服务端发送报文的时候会有一个TIME-WAIT的时间设置规定需要等待2MSL一般的操作系统都是设置成2分钟当然会有部分的操作系统设置的值不一样如在linux操作系统设置的值为1分钟那么接下来需要了解为什么这段第四次挥手需要等待两分钟

首先还是为了保证系统的可靠性如服务端第二次给客户端报文时设置的seq是2000FIN4此时是有4个包但是客户端接收到的seq的值为2002正常是2004少了两个包此时就需要服务端重传第二个原因是如果不设置那么长时间往服务端发送完数据之后直接closed那么就会出现一个问题如果此时服务端发现客户端seq的值少了两个需要服务端这边重传然后客户端这边已经关闭连接如果此时是还是刚刚关闭的客户端发起的一个新的程序并且此时的客户端的操作系统又给这个新的应用程序分配的就是上一个端口号那么此时新的应用程序就会拿到一个上一个服务端第三次挥手重传的数据此时新的应用程序就会处于一个懵圈状态此时就会出现一个报文混乱的状态。

为了保证tcp传输的可靠性因此需要在这里做一个时间等待

确认一个连接就是源ip源端口号目标ip目标端口号上面第二点的第三次握手的报文还是发送在同一个ip的同一个端口号因此还是同一个连接那么新的应用程序就会接收到上一个关闭程序的报文

3.2.2time-wait举例

上面讲了为什么需要time-wait这里举一个在实际开发中可能出现time-wait的案例。

以mysql为例假设在实际开发中用完mysql之后没有主动的去closed如果客户端长时间的没有向服务端发送数据报文发么mysql服务端可能就会认为该客户端已经下线那么服务端就发起断开连接的操作此时由服务端发起第一次挥手服务端第四次挥手响应客户端之后会有一个TIME_WAIT的等待时间假设该操作系统的time-wait是2分钟那么需要再2分钟之后服务端才会closed才能真正的去释放一个连接

如果每次用完mysql都不主动的去closed那么每次都会由服务端去发起断开连接的请求就会产生大量的time-wait服务器会随着客户端的不断增加在某一个时间点会出现资源耗尽的情况如果是一台繁忙的服务器那么就很有可能因为这个time-wait出现宕机的情况。

因此在实际开发中如果是手动的通过JDBC驱动实现mysql的连接那么一定要记得手动的close让客户端去发起断开连接的请求让time-wait这个时间结点出现在客户端这边减少服务端这边的资源损耗。

4UDP协议

udp和tcp都是处于传输层但是udp和tcp底层实现不一样udp属于不可靠连接面向的是无连接的协议就是说客户端发送数据之后不需要去关心服务端是否收到数据udp的特性如下

因为udp在一端发送数据之后不需要关心另一端是否收到数据因此udp会出现丢包的情况

udp也可以不设置另一端的端口号那么可以通过udp实现广播可以让多个端口号接收到数据

由于允许丢包这种那么视频音频这些都可以通过udp的方式实现通信