第一层：物理层。网卡工作在这一层。解决了两台机器的通信，机器A可以收到机器B的比特流（01010101）。涉及到模数(A/D) 和 数模(D/A)转换，将比特流转化成电流强弱，到达目的地后又转化成比特流。为了保证比特流的正确传输，引出数据链路层。
第二层：数据链路层。交换机工作在这一层。定义了数据传输格式，为确保可靠性提供了错误纠正。将比特流包装成帧，从帧中可以获取到目的地址的相关信息。复杂的网络节点中，如果在点对点的数据传输中找到最优路径，引出网络层。
第三层：网络层。路由器工作在这一层。定义了如何将数据包路由发送到接收方。将网络地址转化成物理地址。
第四层：传输层。解决传输质量的问题。接受网络层的数据，分割数据，将数据交给网络层且保证数据能有效达到目的地。
第五层：会话层。建立管理不同用户机器的会话。
第六层：表示层。不同系统间的通讯语法问题。
第七层：应用层。更方便地应用从网络中接收到的数据。
IP协议是无连接的通讯协议，不会占用计算机间的通讯线路。消息被分割成多个包，在计算机间被IP路由到不同目的地。但是IP没有做任何处理来保证数据包是否按顺序传递，故不可靠，需要上层TCP来保证。
IP唯一标识主机，TCP+端口号标识主机的进程。故可以用TCP+IP+端口来标识网络上的主机（套接字socket）
面向非连接，尽最大可能交付
不维护连接状态，支持同时向多个客户端传输相同的消息
数据包报头只有8个字节，额外开销比较小。（TCP有20个字节）
吞吐量只受限与数据生成速率，传输速率和机器性能
面向连接与无连接
可靠性（TCP有握手、确认、重传）
有序性（TCP有序号，有排序）
速度（tcp性能较差，UDP速度快，适合视频、多人在线游戏）
量级（体现在数据报头，UDP报头只有8个字节，TCP有20个字节）
RTT:发送一个数据包到收到对应的ACK所花费的时间
RTO:重传时间间隔（回复ACK则失效）
TCP使用滑动窗口做流量控制与乱序重排
TCP 报头里有个字段 Window。接收方可以通知发送方自己还有多少缓存区可以缓存数据。接收方收到发送方发送的字节并返回ACK，发送方才能移动发送方窗口的左边界，而接收方只有在前面所有字节都接受到了才回移动接收窗口的左边界，否则会等发送方重传数据。
为了初始化Sequeue Number的值，通讯双方要通知对方自己初始化的sequeueNumber,作为以后的通讯序号，以保证数据包不会因为网络问题而乱序。Tcp会用这个序号来拼接数据。
这是一种利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽（CPU满负荷或内存不足）的攻击方式。
解决方法：1.无效连接监视释放。不停监视系统的半开连接和不活动连接，当达到一定阈值时拆除这些连接，从而释放系统资源。（正常连接也会被释放掉）
2.延缓任务控制块（TCB）分配方法（使用Syn Cache和Syn Cookie技术。）
Syn Cache技术： 这种技术是在收到SYN数据报文时不急于去分配TCB，而是先回应一个SYN ACK报文，并在一个专用HASH表（Cache）中保存这种半开连接信息，直到收到正确的回应ACK报文再分配TCB。在FreeBSD系统中这种Cache每个半开连接只需使用160字节，远小于TCB所需的736个字节。在发送的SYN ACK中需要使用一个己方的Sequence Number，这个数字不能被对方猜到，否则对于某些稍微智能一点的Syn Flood攻击软件来说，它们在发送Syn报文后会发送一个ACK报文，如果己方的Sequence Number被对方猜测到，则会被其建立起真正的连接。因此一般采用一些加密算法生成难于预测的Sequence Number。
Syn Cookie技术： 对于SYN攻击，Syn Cache虽然不分配TCB，但是为了判断后续对方发来的ACK报文中的Sequence Number的正确性，还是需要使用一些空间去保存己方生成的Sequence Number等信息，也造成了一些资源的浪费。 Syn Cookie技术则完全不使用任何存储资源，这种方法比较巧妙，它使用一种特殊的算法生成Sequence Number，这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息，以及对方无法知道而己方比较固定的一些信息，如MSS、时间等，在收到对方的ACK报文后，重新计算一遍，看其是否与对方回应报文中的（Sequence Number-1）相同，从而决定是否分配TCB资源。
1.确保有足够的时间让对方收到ack的包，如果被动关闭那端没有收到，就会触发重新发送fin包，一来一去正好是2个msl 2.避免新旧连接混淆。因为有些路由器会缓存ip数据包，延迟收到的包有可能会跟新连接混在一起。
因为tcp是全双工，发送方和接收方都需要FIN报文与ACK报文
Http是一个基于请求-响应的无状态的应用层协议，无状态表示后续想要处理之前的信息，需要重新请求应答。
session存放服务器端，cookie存放在本地。 session如何销毁？1.超时(一般服务器设置超时时间为30分钟)服务器会销毁session；2.点击控制台的红色按钮异常关闭服务器要销毁session。3.手动调用session的invalidate方法session.invalidate(); 服务器正常关闭不销毁session,session存放在服务器内存，也可能是文件，缓存，数据库。 Cookie如何销毁？ 1.代码设置cookie.setMaxAge(0)。2.浏览器清除cookie
1XX:指示信息-请求已被接收，继续处理。
2XX:成功-表示请求已被成功接收、理解。
3XX:重定向-要完成请求需要进行进一步的操作，跳转有关。
4XX:客户端发生错误，语法错误或者请求无法实现
5XX:服务端错误，服务端无法实现合法请求
dns解析。解析域名对应的ip地址（浏览器缓存，系统缓存，路由器缓存，域名服务器缓存） 建立tcp连接。 浏览器向服务器发送http请求 服务器处理请求并返回http报文 浏览器解析渲染页面 浏览器释放tcp连接（4次挥手）
https有ca证书、数据是加密传输、端口为443（http为80）
https传输的数据是加密的，加密方式为：对称加密+非对称加密+数字证书。
为什么不用对称加密？
共用一把密钥，容易被别人窃取。
为什么不用非对称加密？
客户端与服务端分别拥有2把钥匙，服务器用客户端公钥加密，客户端私钥解密。客户端用服务器公钥加密，服务器私钥解密。是可以实现的，但是非对称加密传输速度比对称加密慢百倍。
为什么不用对称加密与非对称加密结合？
服务端发送公钥给客户端，客户端拿到公钥后，自己生成对称密钥，公钥加密密钥后发送给服务器，服务器用私钥解密，拿到密钥后加密传输数据。
这种做法容易被中间人窃取，中间人伪造服务器公钥发送给客户端，拿到客户端传给服务器的公钥加密密钥后可以用自己的私钥解密拿到密钥，这样客户端服务端的数据再怎么加密也没有用了。
所以加上一个数字证书。
多了一步让客户端相信拿到的公钥不是中间人的，而是服务器的公钥。服务器信息经过hash算法形成信息摘要，ca私钥对信息摘要加密后形成数字证书，再和服务器信息一起发送给客户端。客户端在本地内置证书中查找ca公钥，解密拿到信息摘要。对服务器信息进行hash算法后对比加密拿到的信息摘要是否一致，一致表示真的是服务器发过来。
