网络层的一些point

TCP/IP

• TCP（传输控制协议）是一种面向连接的通过失败重传机制确保数据在端到端之间可靠传输的协议。

• IP是面向无连接无状态的么有额外的控制机制保证发送的包是否有序到达。

• 五层模型：应用层、传输层、网络层、链路层、物理层

• 总结一下：程序在发送消息时，应用层按既定的协议打包数据，随后由数据层加上双方端口号，网络层加上双方IP地址，链路层加上双方MAC地址，并且将数据拆分成数据帧，经过多个路由器和网关后到达目的机器。简而言之，就是按“端口--IP地址--MAC地址”这样的路径进行数据的封装和发送。

  • 三次握手：SYN和ACK置0和1，seq 和 ack [序号和应答号] x和y

  • 你听得见吗？

  • 我听得见，你听得见吗？

  • 我也听得见，我们说话吧。

第一次握手：主机A发送位码为syn＝1,随机产生seq number=x的数据包到服务器，客户端进入SYN_SEND状态，等待服务器的确认；主机B由SYN=1知道，A要求建立联机；

第二次握手：主机B收到请求后要确认联机信息，向A发送ack number(主机A的seq+1),syn=1,ack=1,随机产生seq=y的包,此时服务器进入SYN_RECV状态;

第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack number(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1则连接建立成功。客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。

TCP位码,有6种标示:SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)

Sequence number(顺序号码) Acknowledge number(确认号码)

• 四次握手：

  • 我们分手吧

  • 好等我收拾东西，收拾完我告诉你

  • 我收拾完了

  • 好再见

第一次挥手：主机1（可以使客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；

第二次挥手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我也没有数据要发送了，可以进行关闭连接了；

第三次挥手：主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入CLOSE_WAIT状态；

第四次挥手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。

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

虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

2.client发送完最后一个ack之后，进入time_wait状态，但是他怎么知道server有没有收到这个ack呢？莫非sever也要等待一段时间，如果收到了这个ack就close，如果没有收到就再发一个fin给client？这么说server最后也有一个time_wait哦？求解答！

因为网络原因，主动关闭的一方发送的这个ACK包很可能延迟，从而触发被动连接一方重传FIN包。极端情况下，这一去一回，就是两倍的MSL时长。如果主动关闭的一方跳过TIME_WAIT直接进入CLOSED，或者在TIME_WAIT停留的时长不足两倍的MSL，那么当被动关闭的一方早先发出的延迟包到达后，就可能出现类似下面的问题：1.旧的TCP连接已经不存在了，系统此时只能返回RST包2.新的TCP连接被建立起来了，延迟包可能干扰新的连接，这就是为什么time_wait需要等待2MSL时长的原因。

 TCP首部，TCP Flags，3次握手4次分手原因详细解释

四月天：http://www.cnblogs.com/rootq/articles/1377355.html

HTTPS

• 哈希算法：MD5、 SHA

• 对称加密：AES、DES、3DES

• 非对称加密：RSA

• Https握手过程

  • 客户端给出协议版本号、一个客户端随机数A（Client random）以及客户端支持的加密方式

  • 服务端确认双方使用的加密方式，并给出数字证书、一个服务器生成的随机数B（Server random）

  • 客户端确认数字证书有效，生成一个新的随机数C（Pre-master-secret），使用证书中的公钥对C加密，发送给服务端

  • 服务端使用自己的私钥解密出C

  • 客户端和服务器根据约定的加密方法，使用三个随机数ABC，生成对话秘钥，之后的通信都用这个对话秘钥进行加密。