面试知识点小总结

1.并发与并行的区别

并行才是我们通常认为的那个同时做多件事情，而并发则是在线程这个模型下产生的概念。并发表示同时发生了多件事情，通过时间片切换，哪怕只有单一的核心，也可以实现“同时做多件事情”这个效果。
并发是两个任务可以在重叠的时间段内启动，运行和完成。并行是任务在同一时间运行
举个我们开发中会遇到的例子，我们说资源请求并发数达到了1万。这里的意思是有1万个请求同时过来了。但是这里很明显不可能真正的同时去处理这1万个请求的吧！如果这台机器的处理器有4个核心，不考虑超线程，那么我们认为同时会有4个线程在跑。也就是说，并发访问数是1万，而底层真实的并行处理的请求数是4。如果并发数小一些只有4的话，又或者你的机器牛逼有1万个核心，那并发在这里和并行一个效果。也就是说，并发可以是虚拟的同时执行，也可以是真的同时执行。而并行的意思是真的同时执行。
结论是：并行是我们物理时空观下的同时执行，而并发则是操作系统用线程这个模型抽象之后站在线程的视角上看到的“同时”执行。

2.并发处理机制

高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。

提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。前者垂直扩展可以通过提升单机硬件性能，或者提升单机架构性能，来提高并发性，但单机性能总是有极限的，互联网分布式架构设计高并发终极解决方案还是后者：水平扩展。

互联网分层架构中，各层次水平扩展的实践又有所不同：

（1）反向代理层可以通过“DNS轮询”的方式来进行水平扩展；

（2）站点层可以通过nginx来进行水平扩展；

（3）服务层可以通过服务连接池来进行水平扩展；

（4）数据库可以按照数据范围，或者数据哈希的方式来进行水平扩展；

各层实施水平扩展后，能够通过增加服务器数量的方式来提升系统的性能，做到理论上的性能无限。

推荐阅读　什么是高并发 ，详细讲解

3.http 与 https 的区别

1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。

2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。

3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

会话过程

客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤，如图所示。

（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。

（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。

（3）客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。

（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。

（5）Web服务器利用自己的私钥解密出会话密钥。

（6）Web服务器利用会话密钥加密与客户端之间的通信。

推荐阅读　HTTP与HTTPS的区别

4. TCP 三次握手，四次挥手

第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

为什么TCP客户端最后还要发送一次确认呢？

一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。

如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致死锁。
如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

为什么客户端最后还要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

推荐阅读 TCP的三次握手与四次挥手（详解+动图）

5.线程和进程各自有什么区别和优劣呢？

1.进程是资源分配的最小单位，线程是程序执行的最小单位。

2.进程有自己的独立地址空间，每启动一个进程，系统就会为它分配地址空间，建立数据表来维护代码段、堆栈段和数据段，这种操作非常昂贵。而线程是共享进程中的数据的，使用相同的地址空间，因此CPU切换一个线程的花费远比进程要小很多，同时创建一个线程的开销也比进程要小很多。

3.线程之间的通信更方便，同一进程下的线程共享全局变量、静态变量等数据，而进程之间的通信需要以通信的方式（IPC)进行。不过如何处理好同步与互斥是编写多线程程序的难点。

但是多进程程序更健壮，多线程程序只要有一个线程死掉，整个进程也死掉了，而一个进程死掉并不会对另外一个进程造成影响，因为进程有自己独立的地址空间。

6.http有哪些方法？

1、OPTIONS
返回服务器针对特定资源所支持的HTTP请求方法，也可以利用向web服务器发送‘*’的请求来测试服务器的功能性
2、HEAD
向服务器索与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以再不必传输整个响应内容的情况下，就可以获取包含在响应小消息头中的元信息。
3、GET
向特定的资源发出请求。它本质就是发送一个请求来取得服务器上的某一资源。资源通过一组HTTP头和呈现数据（如HTML文本，或者图片或者视频等）返回给客户端。GET请求中，永远不会包含呈现数据。
4、POST
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。 Loadrunner中对应POST请求函数：web_submit_data,web_submit_form
5、PUT
向指定资源位置上传其最新内容
6、DELETE
请求服务器删除Request-URL所标识的资源
7、TRACE
回显服务器收到的请求，主要用于测试或诊断
8、CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

udp tcp 区别

（1）TCP的特点
TCP协议是一种有连接、可靠的、面向字节流、相对比较慢、点对点的传输层协议。TCP协议适用于对可靠性要求比较高的场合。
（2）UDP的特点
UDP协议是一种无连接，不可靠、面向数据报、速度比较快、可实现一对一，多对一的传输层协议。UDP协议适用于对实时性有要求的场合。因为UDP不保证可靠性，所以UDP也没有重传机制，也没有拥塞机制，它只是尽最大努力交付数据。

TCP保证数据可靠性和提高性能的机制

（1）确认应答（ACK）机制
TCP将每个字节的数据都进行了编号，即为序列号。每一个ACK都带有对应的确认序列号，意思是告诉发送者收到了哪些数据，下次从哪里开始发送。

（2）超时重传机制
1）超时重传机制的工作过程
主机A发送数据给B之后，可能因为网络拥堵等问题，数据无法到达主机B。如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发。但是，主机A未收到B发来的确认应答，也可能是因为ACK丢失了，因此主机B会收到很多重复数据。那么TCP协议需要能够识别出哪些包是重复的，并且把重复的丢弃掉，这时候可以利用序列号就可以很容易做到去重的效果。
2）如何确定超时时间？
最理想的情况下找到一个最小的时间，保证“确认应答”一定能在这个时间内返回。但是，这个时间的长短随着网络环境的不同是有差异的，如果超时时间设的太长会影响整体的重传效率；如果超时时间设得太短，有可能会频繁发送重复的包。
TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间。Linux中超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。如果重发一次之后仍然得不到应答，等待2500ms后进行重传；如果仍然得不到应答，等待4500ms再进行重传，以此类推，以指数形式递增。累计到一定的重传次数，TCP认为网络或者对端主机出现异常，并强制关闭连接。

（3）滑动窗口
1）为什么需要滑动窗口？
前面讨论了确认应答策略，对每一个发送的数据段都要给一个ACK确认应答，收到ACK后再发送下一个数据段。这个做有一个比较大的缺点就是性能较差，尤其是数据往返的时间较长的时候。既然这样一发一收性能较低，那么如果一次发送多条数据，不是就可以将多个段的等待时间重叠在一起提高性能了吗？
2）工作过程
窗口大小指的是无须等待确认应答而可以继续发送数据的最大值，规定发送前4个段的时候，需要等待任何ACK直接发送。收到第一个ACK后，滑动窗口向后移动，继续发送第5个段的数据，以此类推。操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答，只有确认应答过的数据才能从缓冲区删掉，窗口越大网络吞吐率就越高。那么如果出现丢包，如何进行重传？
情况一：数据包已经抵达，ACK被丢了。
这种情况下，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认。
情况二：数据包直接丢了。
当某一段报文丢失之后，发送端会一直收到1001这样的ACK，就像是在提醒发送端“接收端想要的就是1001”一样。如果发送端主机连续三次收到了同样一个“1001”，就会将对应的数据1001-2000重新发送.这个时候接收端收到了1001之后，再次返回的ACK就是7001了，因为2001-7000接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中。这种机制被称为“高速重发控制”，也称为“快重传”。

（4）流量控制
1）什么是流量控制？
接收端处理数据的速度是有限的，如果发送端发得太快，导致接收端的缓冲区被填满，这个时候如果发送端继续发送就会造成丢包，继而引起丢包重传等等一系列连锁反应。因此，TCP支持根据接收端的处理能力来决定发送端的发送速度，这个机制就叫做流量控制。
2）工作流程
接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK端通知发送端。窗口大小字段越大，说明网络的吞吐量越高。接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端，发送端接收到这个窗口之后就会减慢自己的发送速度。如果接收端缓冲区满了就会将窗口置为0，这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。
3）接收端如何把窗口大小告诉发送端？
在TCP首部中，有一个16位窗口字段就是用于存放窗口信息的。16位数字最大表示65535，那么TCP窗口最大就是65535字节么？实际上，TCP首部40字节选项中还包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位。

（5）拥塞控制
1)拥塞控制的必要性
虽然TCP有了滑动窗口这个大杀器，能够高效可靠的发送大量数据，但是如果在刚开始阶段就发送大量的数据，仍然可能引发问题。因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵，在不清楚当前网络状态下贸然发送大量的数据，是很有可能雪上加霜的。
2）慢启动
TCP引入慢启动机制，先发少量的数据探探路，摸清当前的网络拥堵状态再决定按照多大的速度传输数据。此处引入一个概念——拥塞窗口，发送开始的时候，定义拥塞窗口大小为1。每次收到一个ACK应答拥塞窗口就加1，每次发送数据包的时候将拥塞窗口和接收端主机反馈的窗口大小做比较，取较小的值作为实际发送的窗口。
3）慢启动阀值
像上面这样的拥塞窗口增长速度是指数级别的。“慢启动”只是指初始时慢，但是增长速度非常快。为了不增长得那么快，因此不能使用拥塞窗口单纯的加倍。此处引入一个叫做慢启动的阀值，当拥塞窗口超过这个阀值的时候，不再按照指数方式增长，而是按照线性方式增长。 当TCP开始启动的时候，慢启动阀值等于窗口最大值，在每次超时重发的时候，慢启动阀值会变成原来的一半，同时拥塞窗口置回1。少量的丢包仅仅是触发超时重传，大量的丢包就会认为是网络拥塞。当TCP通信开始后，网络吞吐量会逐渐上升，随着网络发生拥堵，吞吐量会立刻下降。拥塞控制。归根结底是TCP协议想尽可能快的把数据传输给对方，但是又要避免给网络造成太大的压力的折中方案。（TCP拥塞控制这样的过程就好像热恋的感觉）

（6）延迟应答
如果接收端数据的主机立刻返回ACK应答，这个时候返回的窗口可能性比较小。假设接收端缓冲区为1M,一次收到了500k的数据，如果立刻应答，返回的窗口就是500k。但是实际上可能处理端处理的速度很快，10ms之内就把500k数据从缓冲区消费掉。在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来。如果接收端稍微等一会儿在应答，比如等待200ms在应答，那么这个时候返回的窗口大小就是1M。注意：窗口越大，网络吞吐量就越大，传输效率就越高，应在保证网络不拥塞的情况下尽量提高传输效率。那么所以的包都可以延迟应答么？肯定不行，因为规定有数量限制，每隔N个包就应答一次；而且有时间限制，超过最大延迟时间就应答一次，具体的数量和时间依操作系统不同也有差异，一般N取2，超时时间取200ms。

（7）捎带应答
在延迟应答的基础上，很多情况下客户端服务器在应用层也是“一发一收”的，意味着客户端给服务器说了“how are you”，服务器也会给客户端会一个“Fine，thank 有”，那么这个时候ACK就可以搭顺风车和服务器回应的“Fine，thank you”一起会给客户端。