OSI七层协议模型
- 应用层：有用户自己规定，规定各个应用之间消息传递的形式等，包括各机互访协议，分布式数据库协议等。常见的应用层协议有HTTP协议和FTP协议等。
- 表现层：在满足用户需求的基础上，尽可能的节省传输费用而设置的，比如传输压缩文件，jpeg或者加密文件等格式。
- 会话层：用于建立和拆除会话。
- 传输层：负责将来自会话层的消息传输给网络层，常见的传输层协议有TCP和UDP等协议
- 网络层：规定通信网内的路由选择等方式，建立用户间的信息报传输设施。常见的网络层协议有IP, ICMP以及 ARP等协议。
- 数据链路层：与建立数据传输链路相关
- 物理层：规定一些机电的性能，也包括工作方式如双工、单工或半双工，建立通信的启动与终止等。
TCP和UDP协议的区别
- TCP协议进行数据通信之前需要三次握手建立连接，UDP协议不需要建立连接即可发送数据。
- TCP有确认机制，丢包可以重发，保证数据的正确性；UDP不保证正确性，知识单纯的负责发送数据包。
- TCP协议可能会对大数据包进行拆分，并且在接收方进行冲最数据包操作；UDP协议是面向报文的，不会进行分片和重组，所以需要注意传输的报文大小。
- 网络中的TCP头部为20个字节；UDP头部只有8个字节。
????????网络数据包一般包括头部和数据两部分，在TCP协议中，要发送的数据经过TCP模块添加TCP头部；然后IP模块添加IP头部和MAC头部；然后再最前面加上报头分界符以及末尾这样就构成了一个完整的数据包。
TCP协议中的数据包分片与重组
发送方：将数据分为多个TCP头部+数据包的组合，TCP头部中存放着不同的数据序号；之后将多个组合交给IP模块，添加统一事务IP头部和MAC头部。
接收方：IP模块具有分片重组的功能，如果接收到的数据包是经过分片处理的，就会将其暂存在内部的内存空间中，然后等所有IP头部既有想用ID的包全部到达，因为同一个包的所有分片都具有相同的IP。此外IP头部还有一个分片偏移量的字段，他表示当前分片在整个包中所在的位置，根据这些信息就可以将所有的分片全部收到之后将他们还原成原来的包。
TCP头部信息
?IP头部信息
?ARP地址解析协议
????????地址解析协议，即ARP（Address Resolution Protocol），是根据IP地址获取物理地址的一个TTCP/IP协议。主机发送信息时将包含目标IP地址的ARP请求广播到局域网络上的所有主机，并接收返回消息，以此确定目标的物理地址；收到返回消息后将该IP地址和物理地址存入本机ARP缓存中并保留一定时间，下次请求时直接查询ARP缓存以节约资源。
三次握手四次挥手
- 第一次握手：客户端发送网络包，服务端收到了。
这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。 - 第二次握手：服务端发包，客户端收到了。
这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。 - 第三次握手：客户端发包，服务端收到了。
这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。
试想如果是用两次握手，则会出现下面这种情况：
如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。
简单来说就是两次请求，因为一次请求因为网络的原因导致另外一次成功的连接关闭了之后才到，服务器会认为是又一次的请求，然后就会等待客户端数据的发送，从而浪费资源。
?
- 第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于?
FIN_WAIT1?状态。
即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。 - 第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于?
CLOSE_WAIT?状态。
即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。 - 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于?
LAST_ACK?的状态。
即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。 - 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于?
TIME_WAIT?状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于?CLOSED?状态。
即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。
因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，"你发的FIN报文我收到了"。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。
等待2MSL的意义
- 为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。
- 防止“已失效的连接请求报文段”出现在本连接中。
客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。
HTTP和HTTPS
????????HTTP是超文本传输协议，数据明文传输，而HTTPS=HTTP+SSL（加密）实现了数据的加密传输。HTTP是一种无状态的协议，是一种应用层协议，它规定了通信双方发送的数据的内容格式。HTTP请求信息可以看到当前请求支持的语言，压缩格式，编码格式以及返回文件类型Cookie等信息；返回信息包括响应协议，HTTP Code，时间，Cookie等信息。
常见的HTTP Code
- 1xx（临时响应）
- 2xx（成功）
- 3xx（重定向）表示要完成请求需要进一步操作
- 4xx（错误）表示请求可能出错，服务器处理不了
- 5xx（服务器错误）表示服务器在尝试会处理请求时发生了错误
200（成功）
302（重定向）请求重定向到制定网页
304（未修改）从上次请求后，请求的网页未修改过。服务器不会返回网页内容
401（未授权）请求要求身份验证
403（禁止）服务器拒绝请求
404（未找到）服务器找不到请求的网页
405（方法禁用）服务器找不到请求的网页
500（服务器内部错误）有bug导致程序出错
502（错误网关）服务器接收到了无效的响应
cookie和session
????????cookise是在客户端浏览器的，而session是在服务器端存在的。session需要使用cookie作为识别标志。HTTP协议是无状态的，Session不能依据HTTP连接来判断是否为同一客户，因此服务器向客户端浏览器发送一个名为JSESSIONID的cookie，它的值为该session的id（也就是HttpSession.getId()的返回值）。session依据该cookie来识别是否为同一用户。
????????session是由应用服务器维持的一个服务器端的存储空间，用户在连接服务器时，会由服务器生成一个唯一的sessionid,用该sessionid 为标识符来存取服务器端的session存储空间。而sessionid这一数据则是保存到客户端，用cookie保存的，用户提交页面时，会将这一 sessionid提交到服务器端，来存取session数据。这一过程，是不用开发人员干预的。所以一旦客户端禁用cookie，那么session也会失效。