win7下用iis搭建网站小程序开发流程

1.TCP 三次握手之为什么要三次呢？事不过三？

过程如下图：

先来解释下上述的各个标志的含义

      序列号seq：占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生；给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号。

     确认号ack：占4个字节，期待收到对方下一个报文段的第一个数据字节的序号；序列号表示报文段携带数据的第一个字节的编号；而确认号指的是期望接收到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号。

     确认ACK：占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效

     同步SYN：连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。

     终止FIN：用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接

     ACK、SYN和FIN这些大写的单词表示标志位，其值要么是1，要么是0；ack、seq小写的单词表示序号。

 

三次握手避免历史连接

当客户端连续发送多次建立连接的 SYN 报文，然后在网络拥堵的情况，就会发生客户端收到不正确的 ack 的情况。

具体过程如下：

       客户端先发送了 SYN（seq = 90） 报文，但是被网络阻塞了，服务端并没有收到，接着客户端又重新发送了 SYN（seq = 100） 报文，注意不是重传 SYN，重传的 SYN 的序列号是一样的。
旧 SYN 报文比最新的 SYN  报文早到达了服务端，那么此时服务端就会回一个 SYN + ACK 报文给客户端，此报文的确认号是 91（90+1）。
       客户端收到后，发行自己期望收到的确认号应该是 100+1，而不是 90 + 1，于是就会回 RST 文。
        服务端收到 RST 报文后，就会中止连接。后续最新的 SYN 抵达了服务端后，客户端与服务端就可以正常的完成三次握手了。
       上述中的旧 SYN 报文称为历史连接，TCP 使用三次握手建立连接的最主要原因就是防止历史连接初始化了连接。

       简单来说，三次握手的首要原因是为了防止旧的重复连接初始化造成混乱。

2.如果是两次握手连接，就无法阻止历史连接，那为什么 TCP 两次握手为什么无法阻止历史连接呢？

       因为在两次握手的情况下，被动发起方没有中间状态给主动发起方来阻止历史连接，导致被动发起方可能建立一个历史连接，造成资源浪费。

       两次握手的情况下，被动发起方在收到 SYN 报文后，就进入 ESTABLISHED 状态，意味着这时可以给对方发送数据给，但是主动发起方此时还没有进入 ESTABLISHED 状态，假设这次是历史连接，主动发起方判断到此次连接为历史连接，那么就会回 RST 报文来断开连接，而被动发起方在第一次握手的时候就进入 ESTABLISHED 状态，所以它可以发送数据的，但是它并不知道这个是历史连接，它只有在收到 RST 报文后，才会断开连接。

两次握手无法阻止历史连接

       上面这种场景下，被动发起方在向主动发起方发送数据前，并没有阻止掉历史连接，导致被动发起方建立了一个历史连接，又白白发送了数据，妥妥地浪费了被动发起方的资源。

        因此，要解决这种现象，最好就是在被动发起方发送数据前，也就是建立连接之前，要阻止掉历史连接，这样就不会造成资源浪费，而要实现这个功能，就需要三次握手。

        客户端在 SYN_SENT 状态下，收到不正确的确认号的 syn+ack 报文会回 RST 报文。

3.TCP 三次握手中，客户端收到的第二次握手中 ack 确认号不是自己期望的，会发生什么？是直接丢弃 or 回 RST 报文？

回 RST 报文。

4.什么情况下会收到不正确的 ack（第二次握手中的 ack） 呢？

        当客户端发起多次 SYN 报文，然后网络拥堵的情况下，旧的 SYN 报文比新的 SYN 报文早抵达服务端，此时服务端就会按照收到的旧的 SYN 报文回复 syn+ack 报文，而此报文的确认号并不是客户端期望收到的，于是客户端就会回 RST 报文。

5.四次挥手

        客户端发送FIN包询问服务器端是否能断开，客户端进入FIN_WAIT_1状态
        服务器端收到客户端发送的包并返回ACK包，服务器端进入CLOSE_WAIT状态
        服务器端准备好断开后，发送FIN包给客户端，服务器端进入LAST_ACK状态
        客户端收到服务器端发送的包后返回ACK包，客户端进入TIME_WAIT状态，服务器端收到包后进入CLOSED状态
        客户端状态：FIN_WAIT_1 FIN_WAIT_2 TIME_WAIT
        服务器端状态：CLOSE_WAIT LAST_ACKC LOSED

6.为什么A在TIME-WAIT状态必须等待2MSL（最大报文生存时间）的时间？

        首先保证A发送的最后一个ACK报文段能够到达B，保证A、B正常进入CLOSED状态。

        这个ACK报文段有可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，B超时重传FIN+ACK报文段，A能2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，同时重启2MSL计数器，2MSL时间后A和B进入CLOSE状态，如果A在TIME-WAIT状态时接收到B的FIN+ACK报文段之后向B发出确认报文段，而不再确认B是否收到立即进入CLOSED状态，如若B并没有正常收到A 的确认报文段，则B无法正正常进入到CLOSED状态。

        其次防止“已经失效的连接请求报文段”出现在本连接中。

        A在发送完最后一个ACK报文段并经过2MSL，会使本次连接持续时间内所有产生的报文段消失，保证在下一次新连接中不会出现旧连接遗留的请求报文段。