network basis 01

1.TCP和UDP

TCP(Transmission Control Protocol)：又名传输控制协议，面向连接、提供可靠服务，
    保证传送的数据无差错、不丢失、不重复且按序到达；
    面向字节流，TCP将数据看做一连串无结构的字节流，传输慢；
    有拥塞机制。 点到点通信，首部开销20B，逻辑信道是全双工的可靠信道。

UDP(User Datagram Protocol)：又名用户数据报协议，无连接，不提供可靠服务，
    尽最大努力交付但不保证可靠交付；面向报文，传输快；无拥塞机制，故网络
    出现拥塞不会使源主机的发送速率降低(对实时应用很有用，eg，IP电话、实时视频会议等)。
    支持一对一、一对多、多对一、多对多交互通信，首部8B开销小，不可靠信道。

2.TCP三次握手和四次挥手

TCP链接建立需要三次握手由客户端connect()函数触发。

第一次握手：建立连接时,客户端发送syn包(syn=j)到服务器,
    并进入SYN_SEND状态,等待服务器确认；
    SYN：同步序列编号(Synchronize Sequence Numbers)

第二次握手：服务器收到syn包,必须确认客户的SYN(ack=j+1),
    同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN＋ACK包,向服务器发送确认包ACK(ack=k+1),
    此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手.

clipboard.png

TCP链接拆除需发送四个包，故称为 四次挥手， 客户端或服务器任何一方执行close()都会发起挥手动作 ，四次挥手过程如下：

clipboard.png

3.SYN攻击

在三次握手过程中，服务器发送SYN-ACK之后，
    收到客户端的ACK之前的TCP连接称为半连接(half-open connect)。
    此时服务器处于Syn_RECV状态。当收到ACK后，服务器转入ESTABLISHED状态。

Syn攻击就是 攻击客户端在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，
    服务器回复确认包，并等待客户端的确认，由于源地址是不存在的，服务器需要不断的
    重发直至超时，这些伪造的SYN包将长时间占用未连接队列，
    正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。

Syn攻击是一个典型的DDOS攻击。检测SYN攻击非常的方便，当你在服务器上看到
    大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。
    在Linux下可以如下命令检测是否被Syn攻击：netstat -n -p TCP | grep SYN_RECV

一般较新的TCP/IP协议栈都对这一过程进行修正来防范Syn攻击，修改tcp协议实现。
    主要方法有SynAttackProtect保护机制、SYN cookies技术、
    增加最大半连接和缩短超时时间等。但是不能完全防范syn攻击。

4.为什么建立连接协议是三次握手，而关闭连接却是四次握手

因为服务端的LISTEN状态下的SOCKET当收到SYN报文的连接请求后，
    它可以把ACK和SYN(ACK起应答作用，而SYN起同步作用)放在一个报文里来发送。

但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；
    但未必你所有的数据都全部发送给对方了，所以你可能未必会马上会关闭SOCKET,也即
    你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接，
    所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

5.为什么不能用两次握手进行连接

3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，
    也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

现在把三次握手改成仅需要两次握手，死锁是可能发生的。

作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，
    S收到了这个分组，并发送了确认应答分组。
    按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。
    可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，
    不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，
    C认为连接还未建立成功，将忽略S发来的任何数据分组，只等待连接确认应答分组。
    而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

6.三次握手建立连接时，发送方再次发送确认的必要性

主要是为了防止已失效的连接请求报文段突然又传到了B,因而产生错误。

假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，
    而是在某些网络结点长时间滞留了，一直延迟到连接释放以后的某个时间才到达B，
    本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，
    就误认为是A又发出一次新的连接请求，于是就向A发出确认报文段，同意建立连接。
    假定不采用三次握手，那么只要B发出确认，新的连接就建立了，
    这样一直等待A发来数据，B的许多资源就这样白白浪费了。

7.四次挥手释放连接时，等待2MSL的意义

第一，为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失，
    因而使处在LAST-ACK状态的B收不到对已发送的FIN和ACK 报文段的确认，
    B会超时重传这个FIN和ACK报文段，而A就能在2MSL时间内收到这个重传的ACK+FIN报文段，
    接着A重传一次确认。

第二，就是防止上面提到的已失效的连接请求报文段出现在本连接中，
    A在发送完最后一个ACK报文段后，
    再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。

8.常见的应用中有哪些是应用TCP协议的，哪些又是应用UDP协议的

多播的信息一定要用udp实现，因为tcp只支持一对一通信。

如果一个应用场景中大多是简短的信息，适合用udp实现，因为udp是基于报文段的，
    它直接对上层应用的数据封装成报文段，然后丢在网络中，
    如果信息量太大，会在链路层中被分片，影响传输效率。

如果一个应用场景重性能甚于重完整性和安全性，那么适合于udp，比如多媒体应用，
    缺一两帧不影响用户体验，但是需要流媒体到达的速度快，因此比较适合用udp。

如果要求快速响应，那么udp听起来比较合适。
    如果又要利用udp的快速响应优点，又想可靠传输，那么只能考上层应用自己制定规则了。

常见的使用udp的例子：ICQ,QQ的聊天模块

以QQ为例，登陆采用TCP协议和HTTP协议，你和好友之间发送消息，
    主要采用UDP协议，内网传文件采用了P2P技术。总来的说：

(1)登陆过程，客户端client 采用TCP协议向服务器server发送信息，HTTP协议下载信息。
   登陆之后，会有一个TCP连接来保持在线状态。

(2)和好友发消息，客户端client采用UDP协议，但是需要通过服务器转发。
  腾讯为了确保传输消息的可靠，采用上层协议来保证可靠传输。
  如果消息发送失败，客户端会提示消息发送失败，并可重新发送。

(3)如果是在内网里面的两个客户端传文件，QQ采用的是P2P技术，不需要服务器中转。