五层体系结构包括：应用层、运输层、网络层、数据链路层和物理层。 五层协议只是OSI和TCP/IP的综合，实际应用还是TCP/IP的四层结构。为了方便可以把下两层称为网络接口层。 三种模型结构： 1、物理层：比特 主要定义物理设备标准，如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的主要作用是传输比特流（就是由1、0转化为电流强弱来进行传输,到达目的地后在转化为1、0，也就是我们常说的数模转换与模数转换）。这一层的数据叫做比特。 2、数据链路层：帧 （1）把0、1的信号组成数据包（帧），这是数据链路层的数据包（之后还有IP层 传输层 应用层的数据包）。 （2）数据包的结构都是head+data。 （3）这里的head是数据包的说明项，比如发送者 接受者 数据格式等等，数据链路层的发送者和接受者的数据是MAC地址（网卡的MAC地址，全球唯一） 3、网络层：数据报 因为数据包的发送本质上是把数据包发送给局网中所有的计算机，计算机判断数据包的接受者的MAC地址，如果一致就接收，如果不一致就丢包。 但是计算机网络是在是庞大，给几十亿台计算机每一台发送数据包是不可能的。所以需要新的一组地址来表示计算机的位置。这就是网络层的作用。 判断一个计算机的位置需要IP地址+MAC地址。首先通过IP地址（路由）找到计算机所在的局网，然后广播（发送给每一台计算机）。 4、传输层：报文段/用户数据报 确定计算机上的端口（一个程序占用一个端口）。 定义了一些传输数据的协议和端口号（WWW端口80等），如： TCP（transmission control protocol –传输控制协议，传输效率低，可靠性强，用于传输可靠性要求高，数据量大的数据） UDP（user datagram protocol–用户数据报协议，与TCP特性恰恰相反，用于传输可靠性要求不高，数据量小的数据，如QQ聊天数据就是通过这种方式传输的）。 主要是将从下层接收的数据进行分段和传输，到达目的地址后再进行重组。常常把这一层数据叫做段。 5、应用层：报文 规定应用程序的数据格式，例如Eamil FTP WWW等等。
地址解析协议，即ARP（Address Resolution Protocol），是根据IP地址获取物理地址的一个TCP/IP协议。主机发送信息时将包含目标IP地址的ARP请求广播到网络上的所有主机，并接收返回消息，以此确定目标的物理地址；收到返回消息后将该IP地址和物理地址存入本机ARP缓存中并保留一定时间，下次请求时直接查询ARP缓存以节约资源。地址解析协议是建立在网络中各个主机互相信任的基础上的，网络上的主机可以自主发送ARP应答消息，其他主机收到应答报文时不会检测该报文的真实性就会将其记入本机ARP缓存；由此攻击者就可以向某一主机发送伪ARP应答报文，使其发送的信息无法到达预期的主机或到达错误的主机，这就构成了一个ARP欺骗。ARP命令可用于查询本机ARP缓存中IP地址和MAC地址的对应关系、添加或删除静态对应关系等。相关协议有RARP、代理ARP。NDP用于在IPv6中代替地址解析协议。
IP地址主要分成A, B, C, D, E类, D用于组播,E主要用于科研.这里主要讨论A, B, C类 IP地址是由4个8bit组成的, 一共有2^32个可能的地址. 不同类型的网络是通过第一组8bit来判断的.
A类地址: 0-127...* 二进制:0*******...*B类地址: 128-191...* 二级制: 10******...*C类地址: 192-223...* 二级制: 110***...*在每类网上还有一段地址是用来私有路由的, 不能在广域网上使用
A类:10.0.0.0/8B类: 172.16.0.0/16 - 172.31.0.0/16, 也可以用 172.16.0.0/12 表示C类; 192.168.0.0/24 - 192.168.255.0/24, 也可以用 192.168.0.0/16表最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理，可靠UDP的简单设计。
1、添加seq/ack机制，确保数据发送到对端 2、添加发送和接收缓冲区，主要用于用户超时重传。 3、添加超时重传机制。
详细说明：送端发送数据时，生成一个随机seq=x，然后每一片按照数据大小分配seq。数据到达接收端后接收端放入缓存，并发送一个ack=x+1的包，表示对方已经收到了数据。发送端收到了ack包后，删除缓冲区对应的数据。如果超过一定时间还没收到ack，那么重传数据。
第一，为了保证A发送的最后一个ACK报文能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后就立即释放连接，就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常的步骤进入CLOSED状态。 第二，A在发送完ACK报文段后，再经过2MSL时间，就可以使本连接持续的时间所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求的报文段。
除时间等待计时器外，TCP 还有一个保活计时器（keepalive timer）。设想这样的场景：客户已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然，服务器以后就不能再收到客户端发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就需要使用保活计时器了。
服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两个小时。若两个小时都没有收到客户端的数据，服务端就发送一个探测报文段，以后则每隔 75 秒钟发送一次。若连续发送 10个 探测报文段后仍然无客户端的响应，服务端就认为客户端出了故障，接着就关闭这个连接。
是为了实现传输可靠性的一种协议 原理：每发送一个分组就停止发送，直到收到对方确认才发送写一个分组。 如果等待期间，如果接收方收到重复分组就会自动丢弃，但同时要发送确认。 主要包括以下情况： 1.无差错情况 2.出现差错情况（超时重传） 3.确认丢失 4.确认迟到
自动重传请求 ARQ 协议 停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求 ARQ。
连续 ARQ 协议 连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。
TCP中窗口大小是指tcp协议一次传输多少个数据。因为TCP是一个面向连接的可靠的传输协议，既然是可靠的就需要传输的数据进行确认。 TCP窗口机制有两种，一种是固定窗口大小，另一种是滑动窗口。数据在传输时，TCP会对所有数据进行编号，发送方在发送过程中始终保持着一个窗口，只有落在发送窗口内的数据帧才允许被发送；同时接收方也始终保持着一个接收窗口，只有落在窗口内的数据才会被接收。这样通过改变发送窗口和接收窗口的大小就可以实现流量控制。
一般原理：发生拥塞控制的原因：资源(带宽、交换节点的缓存、处理机)的需求>可用资源。 作用：拥塞控制就是为了防止过多的数据注入到网络中，这样可以使网络中的路由器或者链路不至于过载。拥塞控制要做的都有一个前提：就是网络能够承受现有的网络负荷。 对比流量控制：拥塞控制是一个全局的过程，涉及到所有的主机、路由器、以及降低网络相关的所有因素。流量控制往往指点对点通信量的控制。是端对端的问题。
慢开始拥塞避免快重传快恢复我们都知道TCP属于传输层的协议，传输层除了有TCP协议外还有UDP协议。那么UDP是否会发生粘包或拆包的现象呢？答案是不会。UDP是基于报文发送的，从UDP的帧结构可以看出，在UDP首部采用了16bit来指示UDP数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。而TCP是基于字节流的，虽然应用层和TCP传输层之间的数据交互是大小不等的数据块，但是TCP把这些数据块仅仅看成一连串无结构的字节流，没有边界；另外从TCP的帧结构也可以看出，在TCP的首部没有表示数据长度的字段，基于上面两点，在使用TCP传输数据时，才有粘包或者拆包现象发生的可能。 发生TCP粘包或拆包有很多原因，现列出常见的几点，可能不全面，欢迎补充， 1、要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包。 2、待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。 3、要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。 4、接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。
通过以上分析，我们清楚了粘包或拆包发生的原因，那么如何解决这个问题呢？解决问题的关键在于如何给每个数据包添加边界信息，常用的方法有如下几个： 1、发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。 2、发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。 3、可以在数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开。
301和302状态码都表示重定向，就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取（用户看到的效果就是他输入的地址A瞬间变成了另一个地址B）——这是它们的共同点。他们的不同在于。301表示旧地址A的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；302表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。
• DNS域名解析 • TCP连接 • HTTP请求 • 处理请求返回HTTP响应 • 页面渲染 • 关闭连接
定义：
短连接：例如普通的web请求，在三次握手之后建立连接，发送数据包并得到服务器返回的结果之后，通过客户端和服务端的四次握手进行关闭断开。长连接：区别于短连接，由于三次握手链接及四次握手断开，在请求频繁的情况下，链接请求和断开请求的开销较大，影响效率。采用长连接方式，执行三次握手链接后，不断开链接，保持客户端和服务端通信，直到服务器超时自动断开链接，或者客户端主动断开链接。适用场景：
短连接：适用于网页浏览等数据刷新频度较低的场景。长连接：适用于客户端和服务端通信频繁的场景，例如聊天室，实时游戏等。长连接与短连接区别:
长连接:连接→数据传输→保持连接(心跳)→数据传输→保持连接(心跳)→……→关闭连接（一个TCP连接通道多个读写通信）；短连接:连接→数据传输→关闭连接；HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议是一套加密传输的协议，，TLS/SSL中使用了非对称加密，对称加密以及HASH算法。握手过程的具体描述如下：
浏览器将自己支持的一套加密规则发送给网站。 2.网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。 3.浏览器获得网站证书之后浏览器要做以下工作： a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。 b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。 c) 使用约定好的HASH算法计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。 4.网站接收浏览器发来的数据之后要做以下的操作： a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。 b) 使用密码加密一段握手消息，发送给浏览器。 5.浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。HTTP1.1 的主要变化：
HTTP1.0 经过多年发展，在 1.1 提出了改进。首先是提出了长连接，HTTP 可以在一次 TCP 连接中不断发送请求。
然后 HTTP1.1 支持只发送 header 而不发送 body。原因是先用 header 判断能否成功，再发数据，节约带宽，事实上，post 请求默认就是这样做的。
HTTP1.1 的 host 字段。由于虚拟主机可以支持多个域名，所以一般将域名解析后得到 host。
HTTP2.0 的主要变化：
HTTP2.0 支持多路复用，同一个连接可以并发处理多个请求，方法是把 HTTP数据包拆为多个帧，并发有序的发送，根据序号在另一端进行重组，而不需要一个个 HTTP请求顺序到达；
HTTP2.0 支持服务端推送，就是服务端在 HTTP 请求到达后，除了返回数据之外，还推送了额外的内容给客户端；
HTTP2.0 压缩了请求头，同时基本单位是二进制帧流，这样的数据占用空间更少；
HTTP2.0 适用于 HTTPS 场景，因为其在 HTTP和 TCP 中间加了一层 SSL 层
1、Cookie和Session都是会话技术，Cookie是运行在客户端，Session是运行在服务器端。 2、Cookie有大小限制以及浏览器在存cookie的个数也有限制，Session是没有大小限制和服务器的内存大小有关。 3、Cookie有安全隐患，通过拦截或本地文件找得到你的cookie后可以进行攻击。 4、Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器的压力。
session原理： 1、session是保存在服务器端，理论上是没有是没有限制，只要你的内存够大
2、浏览器第一次访问服务器时会创建一个session对象并返回一个JSESSIONID=ID的值， 创建一个Cookie对象key为JSSIONID，value为ID的值，将这个Cookie写回浏览器
3、浏览器在第二次访问服务器的时候携带Cookie信息JSESSIONID=ID的值，如果该JSESSIONID的session已经销毁， 那么会重新创建一个新的session再返回一个新的JSESSIONID通过Cookie返回到浏览器
4、针对一个web项目，一个浏览器是共享一个session，就算有两个web项目部署在同一个服务器上，针对两个项目的session是不同的 如：你在tomcat上同时部署了两个web项目，分别是web1、web2。当你在一个浏览器上同时访问web1时创建的session是A1，访问web2时创建的session是A2。 后面你再多次访问web1使用的session还是A1,多次访问web2时使用session就是A2
5、session是基于Cookie技术实现，重启浏览器后再次访问原有的连接依然会创建一个新的session， 因为Cookie在关闭浏览器后就会消失，但是原来服务器的Session还在，只有等到了销毁的时间会自动销毁
6、如果浏览器端禁用了Cookie，那么每次访问都会创建一个新的Session，但是我们可以通过服务器端程序重写URL即可，如果页面多连接多，会增加不必要的工作量，
NIO非阻塞方式的Socket编程
传统阻塞方式的Socket编程，在读取或者写入数据时，TCP程序会阻塞直到客户端和服务端成功连接，UDP程序会阻塞直到读取到数据或写入数据。阻塞方式会影响程序性能，JDK5之后的NIO引入了非阻塞方式的Socket编程，非阻塞方式的Socket编程主要是使用Socket通道和Selector通道选择器，将Socket通道注册到通道选择器上，通过通道选择器选择通道已经准备好的事件的进行相应操作。
NIO Socket编程中有一个主要的类Selector,这个类似一个观察者，只要我们把需要探知的套接字通道socketchannel注册到Selector,程序不用阻塞等待，可以并行做别的事情，当有事件发生时，Selector会通知程序，传回一组SelectionKey,程序读取这些Key,就会获得注册过的socketchannel,然后，从这个Channel中读取和处理数据。
Selector内部原理实际是在做一个对所注册的channel的轮询访问，不断的轮询(目前就这一个算法)，一旦轮询到一个channel有所注册的事情发生，比如数据来了，他就会站起来报告，交出一把钥匙，让我们通过这把钥匙来读取这个channel的内容。
