补充面试题(一)

2016.7.25更新...........................................................................

(1)：Cookie和Session的区别

        (1)：Cookie存放在客户端，Session存放在服务端；

        (2)：因为Cookie存在客户端，因为造成了他不安全的特性，很容易通过分析存放在本地的Cookie来进行Cookie欺骗；

        (3)：Session会在一定时间保存在服务器上，因此当访问增多的时候，会占用服务器的资源；

        (4)：单个Cookie保存的数据不能超过4k，很多浏览器限制一个站点最多保存20个Cookie；

(2)：TCP中的三次握手和四次挥手

        三次握手过程：

        (1)：客户端想要和服务端建立连接，首先自己发出请求，请求中令SYN=1表希望和服务端同步，同时附加上自己的序列号seq=a；

        (2)：服务端在收到客户端发来的消息之后，同样发出请求给客户端，此时传递的消息中令SYN=1表示服务端希望和客户端同步，同时附上自己的序列号seq=b，同时还有一个对客户端的确认信息ack，他的值等于客户端序列号+1，即ack=a+1;

        (3)：客户端在收到服务端的回复之后，会再发一条消息给服务端告诉服务端你的恢复我已经收到了，这时候因为之前已经同步过了，所以SYN=0，同时附上自己的序列号seq=a+1，以及对服务端的确认信号ack=b+1;

        注意一点：TCP规定SYN=1时不能携带数据，但是要消耗掉一个序号；

        这样通过三次握手，客户端和服务端建立了TCP连接；

        为什么要三次握手呢？

        目的是为了防止已经失效的报文段突然间又传递给Server端；考虑这样一种情况，client发出第一个连接请求报文段之后并没有丢失，而是在某个网络结点上长时间滞留了，以致于延误到连接释放之后的某个时间才到达server，本来呢，这就是一个早已失效的报文段了，但server在收到此失效的连接请求报文段之后，就误认为是client再次发出一个新的连接请求，于是就向client发出确认报文段，同意建立连接，假设这个时候不采用三次握手的话，那么只要server发出了确认，新的连接就会建立了，由于现在client并没有发出建立连接的请求，因此并不会理睬server的确认，也不会向server发送ack包，因为此时client是处于CLOSED状态的，接收到任何数据包都会丢弃，但server却以为新的连接已经建立，就会一直等待client发送来消息，造成server的资源白白浪费掉，但是采用三次握手的话，可以防止这种现象的出现，在我们的三次握手中，client不会向server发送ack确认信息，那么server由于收不到确认，就知道client并没有要求建立连接，这次连接并不需要建立；

        四次挥手：

        注意一点的是断开连接既可以是客户端先断开也可以是服务端先断开，没有谁先谁后的限制；

        (1)：假如客户端此时想要断开和服务端的连接了，那么此时他会向服务端发送一条消息，消息中带有FIN以及自己的序列号seq = a；

        (2)：服务端在收到客户端的FIN消息之后，会对其进行回复，即回送一条消息告诉客户端我收到你关闭连接的请求的消息了，你可以关了，但是服务端此时关不关是服务端自己的事，以为可能此时服务端仍然有数据需要传递给客户端，回复的消息中包括有一个ACK确认信号，同时有一个确认序列号ack = a+1，以及自己的序列号seq = b;

        (3)：那么此时客户端到服务端的连接就断开了，若此时服务端想要断开和客户端的连接了，那么他也会发送一个FIN消息给客户端，消息中还有服务端自己的序列号seq = b；

        (4)：客户端在收到这个消息之后，会对该消息进行确认，确认消息中包括ACK确认信号以及确认序列号ack = b+1，以及自己的序列号seq = a+1，这样服务端到客户端的连接断开了；

        为什么要四次挥手呢？

        原因在于在关闭连接的时候，当收到对方发来的FIN信号通知之后，仅仅表示对方没有数据发送给你了，但此时未必你的数据已经全部发给对方了，所以没有必要马上关闭你自己，当你把所有数据全部发送给对方的时候，再向对方发送FIN消息告诉他你的数据也发送完毕了，希望断开连接，也就导致了ACK和FIN报文多数情况下是分开发送的情况了；

(3)：Http1.0和Http1.1的区别

        (1)：Http1.0中每一个请求和响应使用的都是新的TCP连接，但是Http1.1中一次TCP连接中可以传送多个Http请求和响应，多个请求和响应可以重叠，可以同时执行；

        (2)：Http1.0中是没有Host请求字段的，Http1.1中在请求字段中加入了该字段，浏览器可以使用主机名来访问Web服务器；

        (3)：Http1.1中支持长连接，但是需要增加新的请求头来实现，也就是我们的Connection头部字段，当该字段的值为"Keep-Alive"的时候，表示客户端通知服务端在返回本次请求结果之后要继续保持连接，当Connection头部字段的值为"close"的时候，表示客户端通知服务端在返回本次请求结果之后断开连接，可见Http1.1的长连接功能也是需要头部字段支持的，而Http1.0是短连接；

        (4)：Http1.1还提供了与Cache有关的请求头和响应头；

        最后注意一点的就是Http协议是无状态协议，即Http服务器端是不维护客户端状态信息的；

(4)：长连接与短连接

        短连接：client和server每进行一次数据交互都要进行连接操作，交互结束连接断开，这种方式适合于一点对多点的通讯，比如Web站点的http服务，因为长连接对于服务器来说要耗费一定的资源，成千上万的用户访问的话使用短连接更加节省资源；

        长连接：client端与server端进行数据交互的时候，先建立连接，但是数据交互结束之后，连接不断开，还能进行后续报文的发送和接收，这种方式适合于点对点通信，比如数据库数据库连接经常使用到的就是长连接，还有就是心跳包的发送也是长连接；

(5)：TCP与UDP的区别：

        (1)：TCP是面向连接的，通信前需要与对方建立连接，UDP是面向非连接的；

        (2)：TCP是可靠传输协议，丢包之后会自动重传，UDP是不可靠协议；

        (3)：TCP有流量控制和拥塞控制，UDP没有；

        (4)：TCP是重量级的，UDP是轻量级的；

        (5)：TCP能够保证数据的顺序，而UDP不可以；

        (6)：TCP采用流模式实现，UDP采用用户数据包模式实现；

(6)：TCP和HTTP区别

        TCP是位于传输层的，Http位于应用层，我们平常见到的Socket是封装了TCP的，而Http又封装了Socket，所以可以认为Http是基于TCP实现的；

(7)：TCP流量控制

        所谓流量控制指的是接收方告诉发送方自己的缓冲区可用空间的大小，从而保证发送方发送的数据不会溢出接收缓冲区，TCP的流量控制主要使用滑动窗口机制实现的，滑动窗口有两个作用，一是提供TCP的可靠性，二是提供TCP的流量可控性，因为TCP是双工通信的，所以发送方和接收方在某一时刻角色可能会发生互换，某一时刻，对于会话的发送方，其发送缓冲内的数据可以分为以下四种：已发送并得到对方ACK的数据、已发送但未得到对方ACK的数据、未发送但对端允许发送的数据、未发送且对端不允许发送的数据，这四种数据中，已发送未得到确认的数据以及未发送但对端允许发送的数据称为发送窗口；会话的接收方缓冲中存在的数据类型分为3种：已接收并回复、未接收准备接收的数据、未接收也不准备接收的数据；滑动窗口中的可靠性是通过"确认重传"实现的，发送窗口只有收到接收方对于本段发送窗口内字节的ACK确认后才会移动发送窗口的左边界，而接收窗口只有在前面所有段都确认的情况下才会移动左边界；发送窗口的大小 = min(接收方窗口大小，拥塞窗口大小)；

(8)：TCP拥塞控制

        因为网络中的中继设备以及狡猾设备本身缓存的限制，当网络的需求超过他们工作极限的时候就会出现拥塞，拥塞控制的目的就是避免过多的数据注入到网络中，以防止网络中的路由器或者链路过载现象的发生，常用的方法是：(1)：慢开始、拥塞避免；(2)：快重传、快恢复；

        慢开始、拥塞避免过程：

        (1)：发送方维持一个叫做"拥塞窗口"的变量，该变量和接收窗口共同决定了发送窗口的大小；

        (2)：当发送方开始发送数据的时候，为了避免一下子向网络中注入过多数据，首先发送1字节的试探报文；

        (3)：如果第一个字节得到确认之后，就会发送一个2字节的报文；

        (4)：若收到2字节的确认之后，则发送4字节，依次递增2的指数级；

        (5)：当到达提前预设的"慢开始门限"时，则从该门限值开始执行拥塞避免算法，每一次往返时间之后将窗口值+1，这样慢慢的线性增长；

        (6)：当出现网络拥塞的时候，则将门限值设置为原先的一半，然后将发送窗口大小置位，变为1，重新开始执行慢开始算法；

        快重传、快恢复过程：

        (1)：当接收方发现丢包之后，会对后续包继续发送针对丢失的那个包的重传请求；

        (2)：一旦发送方接收到三个一样的确认信息，就认为该包在传递的过程中发生了错误，立即重传该包；

        (3)：此时采用的就是"快恢复"算法了，首先会将慢开始门限减半；

        (4)：接着将发送窗口大小设置为慢开始门限的大小，后采用拥塞避免算法，每一个往返时间窗口大小+1，这样线性增长；

(9)：TCP差错控制的方法有哪些？

        通过校验和、确认机制以及超时重传机制

(10)：get和post的区别

        (1)：get用于信息的获取，而且应该是安全的，幂等的，也就是说我们对于同一URL的多个请求应该返回同样的结果，使用get方式仅仅是获取资源而已，不会修改、增加数据；post表示可能会修改服务器上的资源，比如我们通常在qq空间上面的评论操作，因为提交之后会修改服务端的资源；
        (2)：get请求的数据会附在URL后面，以?分割URL和传输的数据，参数之间以&相连接，并且如果是中文的话，会对其进行Base64加密；而post会将提交的数据放置到http包的包体中；
        (3)：很多人说get方式提交的数据最多只能是1024字节，其实不是这样的，URL是不存在参数上限问题的，http协议规范没有对URL长度进行限制，这个限制是特定的浏览器或者服务器设置的；理论上来讲的话，post是没有大小限制的，http规范也没对其进行限制；
        (4)：post的安全性高于get，因为get提交数据会将用户名和密码明文出现在URL上面，很容易被人解密；
        总结一下就是：get是用于向服务器索取数据的请求，而post是用于向服务器提交数据的请求，只是两者的发送机制不同，并不是一个取一个发；

(11)：进程与线程之间的联系与区别

        联系：进程和线程都是可以并发执行的，一个进程中至少有一个线程，进程间的通信实际上是分属于不同进程中的线程之间进行通信的；

        区别：

        (1)：进程是处理器分配资源的基本单位，线程是处理器调度的基本单位；

        (2)：进程之间的数据是不可以共享的，而线程之间的数据是可以共享的；

        (3)：进程的创建和撤销开销要大于线程的创建和撤销开销；

(12)：OSI参考模型与TCP/IP分层

        OSI参考模型分为7层，由下到上分别是：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层；TCP/UDP属于传输层；

        TCP/IP分为4层，由下到上分别是：网络接口层、网络层、运输层、应用层；

(13)：各种排序算法时间复杂度、空间复杂度、稳定性总结

   

(14)：在浏览器中输入网址http://www.baidu.com，从输入到页面在浏览器中显示出来，期间发生了哪些过程

        (1)：首先输入网址，比如：http://www.baidu.com；

        (2)：浏览器查看域名所对应的IP地址，查找流程是：浏览器缓存--->操作系统缓存--->路由器缓存--->ISP的DNS服务器--->根域名服务器；

        (3)：浏览器打开TCP连接(默认端口号是80)，向该IP的服务器发送一条http请求，如果浏览器存储了该域名下的Cookie的话，那么会把Cookie也放入http请求中；

        (4)：该IP对应的服务器很可能是代理服务器，因为有可能你在浏览器中输入的网址是：http://baidu.com而不是http://www.baidu.com，但是按道理这两个网址访问的应该是同一个网站，因此通过代理服务器的方式进行重定向响应，让这两个网址最终访问的是同一个网页；

        (5)：浏览器根据代理服务器的返回地址内容，再次发送http请求；

        (6)：服务器分析http请求，生成http响应，将响应发送给客户端浏览器；

        (7)：浏览器收到响应之后，根据响应内容显示主页框架，同时继续向服务器发送请求，请求的内容是主页里面包含的一些资源，如图片，视频等等；

        (8)：对于静态的页面内容，浏览器通常会进行缓存，而对于动态的内容，通常不会进行缓存，同时缓存的内容是有期限的；

        (9)：浏览器发送异步请求，因为有些页面在显示完成之后客户端仍然需要与服务端保持联系；

        (10)：整个过程结束之后，浏览器关闭TCP连接；

(15)：产生死锁的条件以及避免死锁的方法

        产生死锁的条件：

        (1)：互斥条件：一个资源只能被一个进程使用；

        (2)：请求保持条件：一个进程因为请求资源阻塞时，自己已经获得的资源保持不放；

        (3)：不剥夺条件：进程所获得的资源，在使用结束之前，不能强行剥夺；

        (4)：环路等待条件：形成一个环形的互相请求对方资源的状态；

        避免死锁的方法：

        (1)：资源的有序分配；

        (2)：银行家算法；