Skip to content

Latest commit

 

History

History
84 lines (70 loc) · 9.44 KB

README.md

File metadata and controls

84 lines (70 loc) · 9.44 KB

ioctl网络基础知识

知识列表

介绍TCP连接的三次握手

  • **第一次握手:**建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers);
  • **第二次握手:**服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;
  • **第三次握手:**客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手;

介绍TCP断开的四次挥手

  1. 客户端A发送一个FIN,用来关闭客户A到服务器B的数据传送
  2. 服务器B收到这个FIN,它发回一个ACK,确认序号为收到的序号加1。和SYN一样,一个FIN将占用一个序号
  3. 服务器B关闭与客户端A的连接,发送一个FIN给客户端A
  4. 客户端A发回ACK报文确认,并将确认序号设置为收到序号加1

为什么连接的时候是三次握手,关闭的时候却是四次握手?

因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

  • 网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
  • 可以确保每成功建立一个TCP连接时,来自该连接先前化身的老的重复分组都已经在网络中消逝。

TPC的syn攻击的过程,怎么防御?

  • **过程:**syn攻击是基于TCP连接的三次握手的半连接,属于DOS攻击。攻击者发送完第一次握手后,服务器维护一个未连接队列并发送回复,但是攻击者不发送第三次握手的ack,造成服务器会等待,浪费CPU和内存,在半连接存活时间内有大量的半连接就会造成服务器无法服务现象。
  • **防御:**减小超时时间;SYN网关和SYN代理;如果可以修改协议的话可以参考SCTP的四次握手机制
  • 注意:在TCP四次挥手时也是可以产生DOS攻击的

简述TCP协议在数据传输过程中收发双方是如何保证数据包的可靠性的?

  1. 为了保证数据包的可靠传递,发送方必须把已发送的数据包保留在缓冲区;
  2. 并为每个已发送的数据包启动一个超时定时器;
  3. 如在定时器超时之前收到了对方发来的应答信息(可能是对本包的应答,也可以是对本包后续包的应答),则释放该数据包占用的缓冲区;
  4. 否则,重传该数据包,直到收到应答或重传次数超过规定的最大次数为止。
  5. 接收方收到数据包后,先进行CRC校验,如果正确则把数据交给上层协议,然后给发送方发送一个累计应答包,表明该数据已收到,如果接收方正好也有数据要发给发送方,应答包也可放在数据包中捎带过去。

TCP是如何通过滑动窗口协议实现流量控制和拥塞控制的?

  1. 慢启动阶段(slow start):发送方一开始便向网络发送多个报文段,直至达到接收方通告的窗口大小为止。当发送方和接收方处于同一个局域网时,这种方式是可以的。但是如果在发送方和接收方之间存在多个路由器和速率较慢的链路时,就有可能出现一些问题。一些中间路由器必须缓存分组,并有可能耗尽存储器的空间。
  2. 拥塞避免阶段(congestion avoidance):当发现超时或收到3个相同ACK确认帧时,则表示有丢包事件,此时网络已发生拥塞现象,此时要进行相应的拥塞控制。将慢启动阈值设置为当前拥塞窗口的一半;如检测到超时,拥塞窗口就被置为l。如果拥塞窗口小于或等于慢启动阈值,TCP重新进人慢启动阶段;如果拥塞窗口大于慢启动阈值,TCP执行拥塞避免算法。
  3. 快速重传阶段(fast retransmit):当TCP源端收到到三个相同的ACK副本时,即认为有数据包丢失,则源端重传丢失的数据包,而不必等待RTO超时。同时将ssthresh设置为当前cwnd值的一半,并且将cwnd减为原先的一半。
  4. 快速恢复阶段(fast recovery) :当"旧"数据包离开网络后,才能发送"新"数据包进入网络,即同一时刻在网络中传输的数据包数量是恒定的。如果发送方收到一个重复的ACK,则认为已经有一个数据包离开了网络,于是将拥塞窗口加1。

描述TCP和UDP的区别?

  • TCP是基于连接的,提供可靠传输;而UDP是基于无连接的,不提供可靠传输;
  • UDP报文是面向数据报文的,TCP是面向数据流的;
  • UDP的报文简单,因此传输效率高;
  • TCP只能提供点到点通信,但是UDP支持单播、组播和广播;

TCP有哪些定时器?

  1. **重传计时器:**为了控制丢失的报文段或丢弃的报文段,也就是对报文段确认的等待时间
  2. **坚持计时器:**专门为对付零窗口通知而设立的
  3. **保活计时器:**每当服务器收到客户的信息,就将keeplive timer复位,超时通常设置2小时,若服务器超过2小时还没有收到来自客户的信息,就发送探测报文段,若发送了10个探测报文段(没75秒发送一个)还没收到响应,则终止连接
  4. **时间等待计时器:**在连接终止期使用,当TCP关闭连接时,并不认为这个连接就真正关闭了,在时间等待期间,连接还处于一种中间过度状态。这样就可以时重复的fin报文段在到达终点后被丢弃,这个计时器的值通常设置为一格报文段寿命期望值的两倍。

socket编程

函数
  • fcntl, ioctlsocket, connect, bind, listen, accept, select, poll, epoll, setsockopt
  • send, sendto, sendmsg, write, writev
  • recv, recvfrom, recvmsg, read, readv
描述
  • 可以通过fcntl, ioctlsocket将socket设置为非阻塞模式,通过setsockopt设置超时时间,通过轮询或者select进行收发数据
  • 如果想给connect设置超时可以先通过将socket设置为非阻塞模式,通过setsockopt设置超时时间,然后通过select查询是否连接成功,最后根据实际需要来决定是不是需要将socket设置为非阻塞模式

常见网络攻击

请参见 “http://blog.chinaunix.net/uid-20511624-id-1659108.html”

TCP SYN拒绝服务攻击

目标计算机如果接收到大量的TCP SYN报文,而没有收到发起者的第三次ACK回应,会一直等待,处于这样尴尬状态的半连接如果很多,则会把目标计算机的资源(TCB控制结构)耗尽,而不能响应正常的TCP连接请求

ICMP/UDP洪水

发出端口号从0开始依次递增的TCP SYN或UDP报文, 如果收到了针对这个TCP报文的RST报文,或针对这个UDP报文的ICMP不可达报文,则说明这个端口没有开放, 从而判断出目标计算机开放了哪些TCP或UDP端口

分片IP报文攻击

目标计算机在处理这些分片报文的时候,会把先到的分片报文缓存起来,然后一直等待后续的分片报文,这个过程会消耗掉一部分内存,以及一些IP协议栈的数据结构。如果攻击者给目标计算机只发送一片分片报文,而不发送所有的分片报文,这样攻击者计算机便会一直等待(直到一个内部计时器到时),如果攻击者发送了大量的分片报文,就会消耗掉目标计算机的资源,而导致不能相应正常的IP报文,这也是一种DOS攻击

HTTPS工作过程

TLS/SSL中使用了非对称加密,对称加密以及HASH算法。握手过程的简单描述如下:

  1. 浏览器将自己支持的一套加密规则发送给网站。
  2. 网站从中选出一组加密算法与HASH算法,并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址,加密公钥,以及证书的颁发机构等信息。
  3. 获得网站证书之后浏览器要做以下工作:
    • 验证证书的合法性(颁发证书的机构是否合法,证书中包含的网站地址是否与正在访问的地址一致等),如果证书受信任,则浏览器栏里面会显示一个小锁头,否则会给出证书不受信的提示。
    • 如果证书受信任,或者是用户接受了不受信的证书,浏览器会生成一串随机数的密码,并用证书中提供的公钥加密。
    • 使用约定好的HASH计算握手消息,并使用生成的随机数对消息进行加密,最后将之前生成的所有信息发送给网站。
  4. 网站接收浏览器发来的数据之后要做以下的操作:
    • 使用自己的私钥将信息解密取出密码,使用密码解密浏览器发来的握手消息,并验证HASH是否与浏览器发来的一致。
    • 使用密码加密一段握手消息,发送给浏览器。
  5. 浏览器解密并计算握手消息的HASH,如果与服务端发来的HASH一致,此时握手过程结束,之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。