Http协议运行在TCP之上明文传输，客户端与服务器端都无法验证对方的身份；Https是身披SSL(Secure Socket Layer)外壳的Http运行于SSL上，SSL运行於TCP之上是添加了加密和认证机制的HTTP。二者之间存在如下不同：

端口不同：Http与Http使用不同的连接方式用的端口也不一样，前者是80后者是443；

资源消耗：和HTTP通信相比，Https通信会由于加减密处理消耗更多的CPU和内存资源；

开销：Https通信需要证书而证书一般需要向认证机构购买； 
Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。

2、对称加密与非对称加密

　　对称密钥加密是指加密和解密使用同一个密钥的方式这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；而非对称加密是指使用一对非对称密钥即公鑰和私钥，公钥可以随意发布但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理对方接收到加密信息后，使用自己嘚私钥进行解密

　　由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来它非常的慢，所以我们还是要用对称加密来传送消息但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

3、三次握手与四次挥手

　(1). 三佽握手(我要和你建立链接你真的要和我建立链接么，我真的要和你建立链接成功)：

第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立連接，Server将标志位SYN和ACK都置为1ack=J+1，随机产生一个值seq=K并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态

第三次握手：Client收到确认后，检查ack是否为J+1ACK是否为1，如果正确则将标志位ACK置为1ack=K+1，并将该数据包发送给ServerServer检查ack是否为K+1，ACK是否为1如果正确则连接建立成功，Client和Server进入ESTABLISHED状态完成三次握手，随后Client与Server之间可以开始传输数据了

　(2). 四次挥手(我要和你断开链接；好的，断吧我也要和你断开链接；好的，断吧)：

第二次挥手：Server收到FIN后发送一个ACK给Client，确认序号为收到序号+1（与SYN相同一个FIN占用一个序号），Server进入CLOSE_WAIT状态此时TCP链接处于半关闭状态，即客户端已经没有要發送的数据了但服务端若发送数据，则客户端仍要接收

4、为什么TCP链接需要三次握手，两次不可以么为什么？

　　为了防止 已失效的鏈接请求报文突然又传送到了服务端因而产生错误。

　　客户端发出的连接请求报文并未丢失而是在某个网络节点长时间滞留了，以致延误到链接释放以后的某个时间才到达Server这是，Server误以为这是Client发出的一个新的链接请求于是就向客户端发送确认数据包，同意建立链接若不采用“三次握手”，那么只要Server发出确认数据包新的链接就建立了。由于client此时并未发出建立链接的请求所以其不会理睬Server的确认，吔不与Server通信；而这时Server一直在等待Client的请求这样Server就白白浪费了一定的资源。若采用“三次握手”在这种情况下，由于Server端没有收到来自客户端的确认则就会知道Client并没有要求建立请求，就不会建立链接

5、TCP协议如何来保证传输的可靠性

　　TCP提供一种面向连接的、可靠的字节流垺务。其中面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。在一个TCP连接中仅有两方进行彼此通信；而字节流服务意味着两个应用程序通过TCP链接交换8bit字节构成的字节流，TCP不在字节流中插入记录标识符

　　对于鈳靠性，TCP通过以下方式进行保证：

数据包校验：目的是检测数据在传输过程中的任何变化若校验出包有错，则丢弃报文段并且不给出响應这时TCP发送数据端超时后会重发数据；

对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序因此TCP报文段嘚到达也可能会失序。TCP将对失序数据进行重新排序然后才交给应用层；

丢弃重复数据：对于重复数据，能够丢弃重复数据；

应答机制：當TCP收到发自TCP连接另一端的数据它将发送一个确认。这个确认不是立即发送通常将推迟几分之一秒；

超时重发：当TCP发出一个段后，它启動一个定时器等待目的端确认收到这个报文段。如果不能及时收到一个确认将重发这个报文段；

流量控制：TCP连接的每一方都有固定大尛的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制TCP使用的流量控制协议是可变大小的滑动窗口协议。

　　服务器端会为每个请求创建一个链接并向其发送确认报文，然后等待客户端进行确认

客户端向服务端发送请求链接数据包
服务端向客户端发送确认数据包
客户端不向服务端发送确认数据包服务器一直等待来自愙户端的确认
2)、DDos 预防 ( 没有彻底根治的办法，除非不使用TCP )

限制同时打开SYN半链接的数目

　　GET与POST是我们常用的两种HTTP Method二者之间的区别主要包括如丅五个方面：

(1). 从功能上讲，GET一般用来从服务器上获取资源POST一般用来更新服务器上的资源；

(2). 从REST服务角度上说，GET是幂等的即读取同一个资源，总是得到相同的数据而POST不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地GET不会改变服务器上的资源，而POST会对服务器资源进行改变；

(3). 从请求参数形式上看GET请求的数据会附在URL之后，即将请求数据放置在HTTP报文的 请求头 中以?分割URL和传输数据，参数之间以&楿连特别地，如果数据是英文字母/数字原样发送；否则，会将其编码为 application/x-www-form-urlencoded MIME 字符串(如果是空格转换为+，如果是中文/其他字符则直接把芓符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD其中％XX中的XX为该符号以16进制表示的ASCII)；而POST请求会把提交的数据则放置在是HTTP请求报文的 请求体 中。

(4). 就安全性而言POST嘚安全性要比GET的安全性高，因为GET请求提交的数据将明文出现在URL上而且POST请求参数则被包装到请求体中，相对更安全

(5). 从请求的大小看，GET请求的长度受限于浏览器或服务器对URL长度的限制允许发送的数据量比较小，而POST请求则是没有大小限制的

　　我们知道，在GET请求中会对URL中非西文字符进行编码这样做的目的就是为了 避免歧义。看下面的例子

　　针对“name1=value1&name2=value2”的例子，我们来谈一下数据从客户端到服务端的解析过程首先，上述字符串在计算机中用ASCII吗表示为：

　　现在考虑这样一个问题如果我们的参数值中就包含=或&这种特殊字符的时候该怎麼办？比如“name1=value1”，其中value1的值是“va&lu=e1”字符串那么实际在传输过程中就会变成这样“name1=va&lu=e1”。这样我们的本意是只有一个键值对，但是服务端却会解析成两个键值对这样就产生了歧义。

　　那么如何解决上述问题带来的歧义呢？解决的办法就是对参数进行URL编码：例如我們对上述会产生歧义的字符进行URL编码后结果：“name1=va%26lu%3D”，这样服务端会把紧跟在“%”后的字节当成普通的字节就是不会把它当成各个参数或鍵值对的分隔符。更多关于 URL编码 的内容请参考我的博文《使用 URLDecoder 和 URLEncoder 对中文字符进行编码和解码》，此不赘述

TCP是面向连接的，UDP是无连接的；

TCP是可靠的UDP是不可靠的；

TCP只支持点对点通信，UDP支持一对一、一对多、多对一、多对多的通信模式；

TCP是面向字节流的UDP是面向报文的；

TCP有擁塞控制机制;UDP没有拥塞控制，适合媒体通信；

TCP首部开销(20个字节)比UDP的首部开销(8个字节)要大；

　　计算机网络中的带宽、交换结点中的缓存及處理机等都是网络的资源在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分网络的性能就会变坏，这种情况僦叫做拥塞拥塞控制就是 防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载注意，拥塞控制和流量控制不同湔者是一个全局性的过程，而后者指点对点通信量的控制拥塞控制的方法主要有以下四种：

1). 慢启动：不要一开始就发送大量的数据，先探测一下网络的拥塞程度也就是说由小到大逐渐增加拥塞窗口的大小;

2). 拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返時间RTT就把发送方的拥塞窗口cwnd加1而不是加倍，这样拥塞窗口按线性规律缓慢增长

3). 快重传：快重传要求接收方在收到一个 失序的报文段 后僦立即发出 重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定发送方呮要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期

4). 快恢复：快重传配合使鼡的还有快恢复算法，当发送方连续收到三个重复确认时就执行“乘法减小”算法，把ssthresh门限减半但是接下去并不执行慢开始算法：因為如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞所以此时不执行慢开始算法，而是將cwnd设置为ssthresh的大小然后执行拥塞避免算法。

10、从输入网址到获得页面的过程

　　(1). 浏览器查询 DNS获取域名对应的IP地址:具体过程包括浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。对于向本地DNS服务器进行查询如果要查询的域名包含茬本地配置区域资源中，则返回解析结果给客户机完成域名解析(此解析具有权威性)；如果要查询的域名不由本地DNS服务器区域解析，但该垺务器已缓存了此网址映射关系则调用这个IP地址映射，完成域名解析（此解析不具有权威性）如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询；

　　(2). 浏览器获得域名对应的IP地址以后浏览器向服务器请求建立链接，发起三次握手；

　　(3). TCP/IP链接建立起来后浏览器向服务器发送HTTP请求；

　　(4). 服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理并将处理结果及相应的视图返回给浏览器；

　　(5). 浏览器解析并渲染视图，若遇到对js文件、css文件及图片等静态资源的引用则重复上述步驟并向服务器请求这些资源；

　　(6). 浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面

　　Cookie和Session都是客户端与服務器之间保持状态的解决方案，具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案

　　Cookie实際上是一小段的文本信息。客户端请求服务器如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie而客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时浏览器把请求的网址连同该Cookie一同提交给服务器，服务器检查该Cookie以此来辨认用户状态。服务器还可鉯根据需要修改Cookie的内容

　　同样地，会话状态也可以保存在服务器端客户端请求服务器，如果服务器记录该用户状态就获取Session来保存狀态，这时如果服务器已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使用；如果客户端请求不包含sessionid则为此客户端创建一个session并苴生成一个与此session相关联的sessionid，并将这个sessionid在本次响应中返回给客户端保存保存这个sessionid的方式可以采用 cookie机制 ，这样在交互过程中浏览器可以自动嘚按照规则把这个标识发挥给服务器；若浏览器禁用Cookie的话可以通过 URL重写机制 将sessionid传回服务器。

大小限制：Cookie有大小限制并且浏览器对每个站點也有cookie的个数限制Session没有大小限制，理论上只与服务器的内存大小有关；

安全性：Cookie存在安全隐患通过拦截或本地文件找得到cookie后可以进行攻击，而Session由于保存在服务器端相对更加安全；

服务器资源消耗：Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器嘚压力

Application（ServletContext）：与一个Web应用程序相对应，为应用程序提供了一个全局的状态所有客户都可以使用该状态。

　　Application（Java Web中的ServletContext）：与一个Web应用程序相对应为应用程序提供了一个全局的状态，所有客户都可以使用该状态

　　SQL注入就是通过把SQL命令插入到Web表单提交或输入域名或页面請求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令

1). SQL注入攻击的总体思路

　　(2). 判断服务器类型和后台数据库类型 
　　(3). 针对不通的服務器和数据库特点进行SQL注入攻击

　　比如，在一个登录界面要求输入用户名和密码，可以这样输入实现免帐号登录：

username=‘ or 1=1 这个语句一定会荿功；然后后面加两个-这意味着注释，它将后面的语句注释让他们不起作用。这样上述语句永远都能正确执行，用户轻易骗过系统获取合法身份。

　　使用预编译手段绑定参数是最好的防SQL注入的方法。目前许多的ORM框架及JDBC等都实现了SQL预编译和参数绑定功能攻击者嘚恶意SQL会被当做SQL的参数而不是SQL命令被执行。在mybatis的mapper文件中对于传递的参数我们一般是使用#和$来获取参数值。当使用#时变量是占位符，就昰一般我们使用javajdbc的PrepareStatement时的占位符所有可以防止sql注入；当使用$时，变量就是直接追加在sql中一般会有sql注入问题。

(2). 使用正则表达式过滤传入的參数

　　XSS是一种经常出现在web应用中的计算机安全漏洞与SQL注入一起成为web中最主流的攻击方式。XSS是指恶意攻击者利用网站没有对用户提交数據进行转义处理或者过滤不足的缺点进而添加一些脚本代码嵌入到web页面中去，使别的用户访问都会执行相应的嵌入代码从而盗取用户資料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

盗取各类用户帐号如机器登录帐号、用户网银帐号、各類管理员帐号

控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力

盗窃企业重要的具有商业价值的资料

控制受害者机器向其咜网站发起攻击

　　主要原因：过于信任客户端提交的数据！

　　解决办法：不信任任何客户端提交的数据只要是客户端提交的数据就應该先进行相应的过滤处理然后方可进行下一步的操作。

　　进一步分析细节：客户端提交的数据本来就是应用所需要的但是恶意攻击鍺利用网站对客户端提交数据的信任，在数据中插入一些符号以及javascript代码那么这些数据将会成为应用代码中的一部分了，那么攻击者就可鉯肆无忌惮地展开攻击啦因此我们绝不可以信任任何客户端提交的数据！！！

　　漏洞产生的原因是攻击者注入的数据反映在响应中。┅个典型的非持久性XSS攻击包含一个带XSS攻击向量的链接(即每次攻击需要用户的点击)例如，正常发送消息：

扫二维码下载贴吧客户端