剑指Offer题目解析请看这里
LeetCode经典题目解析请看这里
操作系统面试知识点汇总，请看这里
数据结构面试常见内容汇总，请看这里
1. TCP/IP模型
TCP/IP协议模型（Transmission Control Protocol/Internet Protocol），包含了一系列构成互联网基础的网络协议，是Internet的核心协议。
基于TCP/IP的参考模型将协议分成四个层次，它们分别是链路层、网络层、传输层和应用层。下图表示TCP/IP模型与OSI模型各层的对照关系。
每层的作用
应用层： 应用层直接为用户的应用进程提供服务，确定进程之间通信的性质以满足用户的需要。应用层不仅要提供应用进程所需要的信息交换和远地操作， 而且还要作为互相作用的应用进程的用户代理， 来完成一些为进行语义上有意义的信息交换所必须的功能。
传输层：传输层的任务就是负责主机中两个进程之间的通信，传输单位为报文。
网络层：网络层负责为分组交换网上的不同主机提供通信。 在发送数据时， 网络层将运输层产生的报文段或用户数据报封装成分组或包进行传送。 网络层的另一个任务就是要选择合适的路由， 使源主机运输层所传下来的分组能够交付到目的主机。传输单位为包。
数据链路层：数据链路层的任务是将在网络层交下来的 IP 数据包组装成帧， 在两个相邻结点间的链路上传送以帧为单位的数据。
物理层：物理层的任务就是通过媒介透明地传送比特流。 在物理层上所传数据的单位是比特。
TCP/IP协议族按照层次由上到下，层层包装。最上面的是应用层，这里面有http，ftp,等等我们熟悉的协议。而第二层则是传输层，著名的TCP和UDP协议就在这个层次。第三层是网络层，IP协议就在这里，它负责对数据加上IP地址和其他的数据以确定传输的目标。第四层是数据链路层，这个层次为待传送的数据加入一个以太网协议头，并进行CRC编码，为最后的数据传输做准备。
上图清楚地表示了TCP/IP协议中每个层的作用，而TCP/IP协议通信的过程其实就对应着数据入栈与出栈的过程。入栈的过程，数据发送方每层不断地封装首部与尾部，添加一些传输的信息，确保能传输到目的地。出栈的过程，数据接收方每层不断地拆除首部与尾部，得到最终传输的数据。
上图以HTTP协议为例，具体说明。
2. 物理层和数据链路层
2.1 物理层
物理层主要定义物理设备标准，如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。
它的主要作用是传输数据比特流（就是由1、0转化为电流强弱来进行传输，到达目的地后在转化为1、0。
2.2 数据链路层
物理层为我们提供了在两台设备之间传输0和1的可能，但是只是单纯的传输0和1是没有意义的。
数据链路层负责将0、1信号序列化，转化为有意义的数据帧，从一个节点传输到临近的另一个节点。这些节点是通过MAC来唯一标识的(MAC,物理地址，一个主机会有一个MAC地址)。
2.2.1 以太网协议
以太网协议用来定义这些01电信号，使得这些电信号变得有意义。一组电信号构成一个数据包，叫做"帧"（Frame）。每一帧分成两个部分：标头（Head）和数据（Data）。
head包含（固定18字节）：发送者（源地址，6个字节）；接收者（目标地址，6个字节）；数据类型（6个字节）
data包含：（最短46字节，最长1500字节）数据包的具体内容。
2.2.2 MAC地址
网卡的地址，就是数据包的发送地址和接收地址，这叫做MAC地址。每块网卡出厂的时候，都有一个全世界独一无二的MAC地址。
2.2.3 广播
发送数据时，将向网络中所有设备都发送这个消息，然后每一台设备自己来判断数据标头中包含的MAC地址是否和自己的MAC地址一致，如果一致就接收这个消息，如果不一致就不接收。这种发送数据的方式叫做“广播”。通过“广播”的方式就可以把一条数据发送到指定设备上了。
有了数据包的定义、网卡的MAC地址、广播的发送方式，"链接层"就可以在多台计算机之间传送数据了。
数据链路层的交互过程
数据链层用 mac 地址作为通信目标， 数据包到达网络层准备往数据链路层发送的时候， 首先会去自己的 arp 缓存表(存着 ip-mac 对应关系)去查找改目标 ip 的 mac 地址， 如果查到了， 就讲目标 ip 的 mac 地址封装到链路层数据包的包头。 如果缓存中没有找到， 会发起一个广播，所有收到的广播的机器看这个 ip 是不是自己的， 如果是自己的， 则以单拨的形式将自己的 mac 地址回复给请求的机器。
3. 网络层
“广播”的方式只能在同一子网络内发送数据。也就是说，如果两台计算机不在同一个子网络，广播是传不过去的。
因此，必须找到一种方法，能够区分哪些MAC地址属于同一个子网络，哪些不是。如果是同一个子网络，就采用广播方式发送，否则就采用"路由"方式发送。（"路由"的意思，就是指如何向不同的子网络分发数据包）遗憾的是，MAC地址本身无法做到这一点。它只与厂商有关，与所处网络无关。
这就导致了"网络层"的诞生。它的作用是引进一套新的地址，使得我们能够区分不同的计算机是否属于同一个子网络。这套地址就叫做"网络地址"，简称"网址"。
于是，"网络层"出现以后，每台计算机有了两种地址，一种是MAC地址，另一种是网络地址。两种地址之间没有任何联系，MAC地址是绑定在网卡上的，网络地址则是管理员分配的，它们只是随机组合在一起。
网络地址帮助我们确定计算机所在的子网络，MAC地址则将数据包送到该子网络中的目标网卡。因此，从逻辑上可以推断，必定是先处理网络地址，然后再处理MAC地址。
3.1 IP协议
规定网络地址的协议，叫做IP协议。它所定义的地址，就被称为IP地址。IP协议是TCP/IP协议的核心，所有的TCP，UDP，IMCP，IGMP的数据都以IP数据格式传输。要注意的是，IP不是可靠的协议，这是说，IP协议没有提供一种数据未传达以后的处理机制，这被认为是上层协议：TCP或UDP要做的事情。
IP地址
习惯上，我们用分成四段的十进制数表示IP地址，从0.0.0.0一直到255.255.255.255。
互联网上的每一台计算机，都会分配到一个IP地址。这个地址分成两个部分，前一部分代表网络，后一部分代表主机。比如，IP地址172.16.254.1，这是一个32位的地址，假定它的网络部分是前24位（172.16.254），那么主机部分就是后8位（最后的那个1）。处于同一个子网络的电脑，它们IP地址的网络部分必定是相同的，也就是说172.16.254.2应该与172.16.254.1处在同一个子网络。
但是，问题在于单单从IP地址，我们无法判断网络部分。还是以172.16.254.1为例，它的网络部分，到底是前24位，还是前16位，甚至前28位，从IP地址上是看不出来的。
从IP地址判断两台计算机是否属于同一个子网络，这就要用到另一个参数"子网掩码"（subnet mask）。子网掩码，就是表示子网络特征的一个参数。它在形式上等同于IP地址，也是一个32位二进制数字，它的网络部分全部为1，主机部分全部为0。比如，IP地址172.16.254.1，如果已知网络部分是前24位，主机部分是后8位，那么子网络掩码就是11111111.11111111.11111111.00000000，写成十进制就是255.255.255.0。
知道"子网掩码"，我们就能判断，任意两个IP地址是否处在同一个子网络。方法是将两个IP地址与子网掩码分别进行AND运算（两个数位都为1，运算结果为1，否则为0），然后比较结果是否相同，如果是的话，就表明它们在同一个子网络中，否则就不是。
比如，已知IP地址172.16.254.1和172.16.254.233的子网掩码都是255.255.255.0，请问它们是否在同一个子网络？两者与子网掩码分别进行AND运算，结果都是172.16.254.0，因此它们在同一个子网络。
总结一下，IP协议的作用主要有两个，一个是为每一台计算机分配IP地址，另一个是确定哪些地址在同一个子网络。
IP地址和MAC地址
MAC 地址是一个硬件地址， 用来定义网络设备的位置， 主要由数据链路层负责。 而 IP 地址是 IP 协议提供的一种统一的地址格式， 为互联网上的每一个网络和每一台主机分配一个逻辑地址， 以此来屏蔽物理地址的差异。
3.2 ARP协议
因为IP数据包是放在以太网数据包里发送的，所以我们必须同时知道两个地址，一个是对方的MAC地址，另一个是对方的IP地址。通常情况下，对方的IP地址是已知的，但是我们不知道它的MAC地址。
ARP协议是“Address Resolution Protocol”（地址解析协议）的缩写。所谓“地址解析”就是主机在发送帧前将目标IP地址转换成目标MAC地址的过程。ARP协议的基本功能就是通过目标设备的IP地址，查询目标设备的MAC地址，以保证通信的顺利进行。
当主机要发送一个IP包的时候，会首先查一下自己的ARP高速缓存（就是一个IP-MAC地址对应表缓存）。
如果查询的IP－MAC值对不存在，那么主机就向网络发送一个ARP协议广播包，这个广播包里面就有待查询的IP地址，而直接收到这份广播包的所有主机都会查询自己的IP地址，如果两者相同，就做出回复，向对方报告自己的MAC地址，否则就丢弃这个包，这样就可以通过IP地址获取到MAC地址了。
3.3 ICMP协议
IP协议并不是一个可靠的协议，它不保证数据被送达，那么，自然的，保证数据送达的工作应该由其他的模块来完成。其中一个重要的模块就是ICMP(网络控制报文)协议。ICMP不是高层协议，而是IP层的协议。
当传送IP数据包发生错误。比如主机不可达，路由不可达等等，ICMP协议将会把错误信息封包，然后传送回给主机。给主机一个处理错误的机会，这 也就是为什么说建立在IP层以上的协议是可能做到安全的原因。
3.3.1 ping
ping可以说是ICMP的最著名的应用，是TCP/IP协议的一部分。利用“ping”命令可以检查网络是否连通，可以很好地帮助我们分析和判定网络故障。
ing这个单词源自声纳定位，而这个程序的作用也确实如此，它利用ICMP协议包来侦测另一个主机是否可达。原理是用类型码为0的ICMP发请 求，受到请求的主机则用类型码为8的ICMP回应。
ping程序来计算间隔时间，并计算有多少个包被送达。用户就可以判断网络大致的情况。
3.3.2 Traceroute
Traceroute是用来侦测主机到目的主机之间所经路由情况的重要工具，也是最便利的工具。
Traceroute的原理是非常非常的有意思，它收到到目的主机的IP后，首先给目的主机发送一个TTL=1的UDP数据包，而经过的第一个路由器收到这个数据包以后，就自动把TTL减1，而TTL变为0以后，路由器就把这个包给抛弃了，并同时产生 一个主机不可达的ICMP数据报给主机。主机收到这个数据报以后再发一个TTL=2的UDP数据报给目的主机，然后刺激第二个路由器给主机发ICMP数据 报。如此往复直到到达目的主机。这样，traceroute就拿到了所有的路由器IP。
4. 传输层
4.1 TCP三次握手和四次挥手
TCP标志位有6种：SYN（建立联机）、ACK（确认）、PSH（传送）、FIN（结束）、RST（重置）、URG（紧急）。Sequence number（顺序号码）、Acknowledge number（确认号码）。
4.1.1 三次握手
第一次握手： 建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number（顺序号码）为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；
第二次握手： 服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number（确认号码）为x+1；同时，自己自己还要发送SYN请求信息，将SYN位置为1，顺序号码为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；
第三次握手： 客户端收到服务器的SYN+ACK报文段。然后将确认号码设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。
为什么要三次握手？
为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
具体例子：“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”
为什么不用四次？
本来握手应该和挥手一样都是需要确认两个方向都能联通的， 本来模型应该是：
1.客户端发送 syn0 给服务器
2.服务器收到 syn0， 回复 ack(syn0+1)
3.服务器发送 syn1
4.客户端收到 syn1， 回复 ack(syn1+1)
因为 tcp 是全双工的， 上边的四部确认了数据在两个方向上都是可以正确到达的， 但是 2， 3 步没有上下的联系， 可以将其合并， 加快握手效率， 所有就变成了 3 步握手。
4.1.2 四次挥手
第一次分手： 主机1（可以使客户端，也可以是服务器端），设置Sequence Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；
第二次分手： 主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我“同意”你的关闭请求；
第三次分手： 主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST_ACK状态；
第四次分手： 主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，然后主机1也可以关闭连接了。
为什么要四次分手？
TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。
为什么要等待2MSL？
MSL：报文段最大生存时间，它是任何报文段被丢弃前在网络内的最长时间。
原因有二：保证TCP协议的全双工连接能够可靠关闭；保证这次连接的重复数据段从网络中消失
第一点：如果主机1直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致主机2没有收到主机1最后回复的ACK。那么主机2就会在超时之后继续发送FIN，此时由于主机1已经CLOSED了，就找不到与重发的FIN对应的连接。所以，主机1不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。
第二点：如果主机1直接CLOSED，然后又再向主机2发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达主机2，由于新连接和老连接的端口号是一样的，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。
4.2 TCP流量控制
如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。
利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗口是 rwnd = 400 ”(这里的 rwnd 表示 receiver window) 。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。请注意，TCP的窗口单位是字节，不是报文段。假设每一个报文段为100字节长，而数据报文段序号的初始值设为1。大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值ack。
从图中可以看出，B进行了三次流量控制。第一次把窗口减少到 rwnd = 300 ，第二次又减到了 rwnd = 100 ，最后减到 rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。B向A发送的三个报文段都设置了 ACK = 1 ，只有在ACK=1时确认号字段才有意义。
TCP为每一个连接设有一个持续计时器(persistence timer)。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口控测报文段（携1字节的数据），那么收到这个报文段的一方就重新设置持续计时器。
4.3 TCP拥塞控制
发送方维持一个拥塞窗口 cwnd ( congestion window )的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。
发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。
4.3.1 慢开始和拥塞避免
慢开始算法：
当主机开始发送数据时，如果立即所大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此，较好的方法是 先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。
通常在刚刚开始发送报文段时，先把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口 cwnd ，可以使分组注入到网络的速率更加合理。
每经过一个传输轮次，拥塞窗口 cwnd 就加倍。一个传输轮次所经历的时间其实就是往返时间RTT。不过“传输轮次”更加强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。
另，慢开始的“慢”并不是指cwnd的增长速率慢，而是指在TCP开始发送报文段时先设置cwnd=1，使得发送方在开始时只发送一个报文段（目的是试探一下网络的拥塞情况），然后再逐渐增大cwnd。
为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量。慢开始门限ssthresh的用法如下：
当 cwnd < ssthresh 时，使用上述的慢开始算法。
当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。
拥塞避免
让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。
无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。
这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生 拥塞的路由器有足够时间把队列中积压的分组处理完毕。
4.3.2 快重传和快恢复
快重传
快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时才进行捎带确认。快重传算法还规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段M3，而不必 继续等待M3设置的重传计时器到期。
快恢复
当发送方连续收到三个重复确认，就执行“乘法减小”算法，把慢开始门限设置为出现拥塞时的发送方窗口值的一半。
与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为当前慢开始门限ssthresh值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。
4.4 TCP怎么保证可靠性
TCP协议保证数据传输可靠性的方式主要有：
（1）序列号、确认应答、超时重传
数据到达接收方， 接收方需要发出一个确认应答， 表示已经收到该数据段， 并且确认序号会说明它下一次需要接收的数据序列号。 如果发送方迟迟未收到确认应答， 那么可能是发送的数据丢失， 也可能是确认应答丢失， 这时发送方在等待一定时间后会进行重传。
（2）连接管理
三次握手保证建立可靠的连接。
（3） 流量控制
如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。
（4）拥塞控制
如果把窗口定的很大， 发送端连续发送大量的数据， 可能会造成网络的拥堵， 甚至造成网络的瘫痪。 所以 TCP 在为了防止这种情况而进行了拥塞控制。
4.5 TCP和UDP的区别
TCP/UDP都是是传输层协议，但是两者具有不同的特性，同时也具有不同的应用场景，下面以图表的形式对比分析。
1） 连接
TCP 是面向连接的传输层协议， 即传输数据之前必须先建立好连接；UDP 无连接。
2） 服务对象
TCP 是点对点的两点间服务， 即一条 TCP 连接只能有两个端点；UDP 支持一对一， 一对多， 多对一， 多对多的交互通信。
3） 可靠性
TCP 是可靠交付： 无差错， 不丢失， 不重复， 按序到达。UDP 是尽最大努力交付， 不保证可靠交付。
4） 拥塞控制， 流量控制
TCP 有拥塞控制和流量控制保证数据传输的安全性。UDP 没有拥塞控制， 网络拥塞不会影响源主机的发送效率。
5） 报文长度
TCP 是动态报文长度， 即 TCP 报文长度是根据接收方的窗口大小和当前网络拥塞情况决定的。UDP 面向报文， 不合并， 不拆分， 保留上面传下来报文的边界。
6) 首部开销
TCP 首部开销大， 首部 20 个字节。UDP 首部开销小， 8 字节。 （源端口， 目的端口， 数据长度， 校验和）
TCP和UDP的适用场景
当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。
当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，这时就可以使用UDP。
区分UDP和TCP
根据端口区分传递到IP层的保文应该给哪个程序；通过看IP头中的协议标识字段区分UDP报头和TCP报头，17是UDP，6是TCP。
5. 应用层
5.1 HTTP和HTTPS协议
5.1.1 HTTP协议
HTTP 协议是 Hyper Text Transfer Protocol（超文本传输协议） 的缩写， 是用于从万维网（WWW:World Wide Web） 服务器传输超文本到本地浏览器的传送协议。HTTP 是一个属于应用层的面向对象的协议，是基于 TCP/IP 通信协议来传递数据（HTML 文件， 图片文件， 查询结果等）， 由于其简捷、 快速的方式， 适用于分布式超媒体信息系统。
HTTP协议特点
1、 简单快速：
客户向服务器请求服务时， 只需传送请求方法和路径。 请求方法常用的有GET、 HEAD、 POST。每种方法规定了客户与服务器联系的类型不同。
2、 灵活：
HTTP 允许传输任意类型的数据对象。
3、 无连接：
无连接的含义是限制每次连接只处理一个请求。 服务器处理完客户的请求， 并收到客户的应答后， 即断开连接。 采用这种方式可以节省传输时间。
4、 无状态：
HTTP 协议是无状态协议。 无状态是指协议对于事务处理没有记忆能力。 缺少状态意味着如果后续处理需要前面的信息， 则它必须重传， 这样可能导致每次连接传送的数据量增大。 另一方面， 在服务器不需要先前信息时它的应答就较快。
5、 默认端口 80
6、 基于 TCP 协议
HTTP过程概述
HTTP 请求/响应的步骤如下：
1、 客户端连接到 Web 服务器
浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址；解析出 IP 地址后， 根据该 IP 地址和默认端口 80， 和服务器建立 TCP 连接；
2、 发送 HTTP 请求
客户端向 Web 服务器发送一个文本的请求报文， 一个请求报文由请求行、请求头部、 空行和请求数据 4 部分组成。
3、 服务器接受请求并返回 HTTP 响应
Web 服务器解析请求， 定位请求资源。 服务器将资源复本写到 TCP 套接字， 由客户端读取。一个响应由状态行、 响应头部、 空行和响应数据 4 部分组成。
4、 释放 TCP 连接
若 connection 模式为 close， 则服务器主动关闭 TCP 连接， 客户端被动关闭连接， 释放TCP连接；若 connection 模式为 keepalive， 则该连接会保持一段间， 在该时间内可以继续接收请求;
5、 客户端浏览器解析 HTML 内容
客户端浏览器首先解析状态行， 查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的 HTML 文档和文档的字符集。 客户端浏览器读取响应数据 HTML， 根据 HTML 的语法对其进行格式化， 并在浏览器窗口中显示。
HTTP返回码
HTTP 协议的响应报文由状态行、 响应头部和响应包体组成， 其响应状态码总体描述如下：
1xx： 指示信息–表示请求已接收， 继续处理。
2xx： 成功–表示请求已被成功接收、 理解、 接受。
3xx： 重定向–要完成请求必须进行更进一步的操作。
4xx： 客户端错误–请求有语法错误或请求无法实现。
5xx： 服务器端错误–服务器未能实现合法的请求。
** GET 和 POST 的区别**
1、 概括
对于 GET 方式的请求， 浏览器会把 http header 和 data 一并发送出去， 服务器响应 200（返回数据） ；而对于 POST， 浏览器先发送 header， 服务器响应 100， 浏览器再发送 data， 服务器响应 200（返回数据）
2、 区别：
1)、 get 参数通过 url 传递， post 放在 request body 中。
2)、 get 请求在 url 中传递的参数是有长度限制的， 而 post 没有。
3)、 get 比 post 更不安全， 因为参数直接暴露在 url 中， 所以不能用来传递敏感信息。
4)、 get 请求只能进行 url 编码， 而 post 支持多种编码方式。
5)、 get 请求会浏览器主动 cache， 而 post 支持多种编码方式。
6)、 get 请求参数会被完整保留在浏览历史记录里， 而 post 中的参数不会被保留。
7)、 GET 和 POST 本质上就是 TCP 链接， 并无差别。 但是由于 HTTP 的规定和浏览器/服务器的限制， 导致他们在应用过程中体现出一些不同。
8)、 GET 产生一个 TCP 数据包； POST 产生两个 TCP 数据包。
5.1.1 区别
HTTP 协议和 HTTPS 协议区别如下：
1） HTTP 协议是以明文的方式在网络中传输数据， 而 HTTPS 协议传输的数据则是经过 TLS 加密后的， HTTPS 具有更高的安全性；
2） HTTPS 在 TCP 三次握手阶段之后， 还需要进行 SSL 的 握手， 协商加密使用的对称加密密钥；
3） HTTPS 协议需要服务端申请证书， 浏览器端安装对应的根证书；
4） HTTP 协议端口是 80， HTTPS 协议端口是 443。
5.1.2 HTTPS的优缺点
HTTPS 优点：
HTTPS 传输数据过程中使用密钥进行加密， 所以安全性更高；
HTTPS 协议可以认证用户和服务器， 确保数据发送到正确的用户和服务器。
HTTPS 缺点：
HTTPS 握手阶段延时较高： 由于在进行 HTTP 会话之前还需要进行 SSL 握手， 因此 HTTPS 协议握手阶段延时增加；
HTTPS 部署成本高： 一方面 HTTPS 协议需要使用证书来验证自身的安全性， 所以需要购买 CA证书； 另一方面由于采用 HTTPS 协议需要进行加解密的计算， 占用 CPU 资源较多， 需要的服务器配置或数目高。
5.2 DNS协议
DNS协议则是用来将域名转换为IP地址（也可以将IP地址转换为相应的域名地址）。
我们都知道，TCP/IP中使用的是IP地址和端口号来确定网络上某一台主机上的某一个程序，不免有人有疑问，为什么不用域名来直接进行通信呢？
- 因为IP地址是固定长度的，IPv4是32位，IPv6是128位，而域名是变长的，不便于计算机处理。
- IP地址对于用户来说不方便记忆，但域名便于用户使用，例如www.baidu.com这是百度的域名。
总结一点就是IP地址是面向主机的，而域名则是面向用户的。
DNS（Domain Name System，域名系统），因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析（或主机名解析）。
浏览器中输入 URL，要将 URL 解析为 IP 地址， 解析域名就要用到 DNS 协议， 首先主机会查询 DNS 的缓存，如果没有就给本地 DNS 发送查询请求。 DNS 查询分为两种方式， 一种是递归查询， 一种是迭代查询。 如果是迭代查询， 本地的 DNS 服务器， 向根域名服务器发送查询请求， 根域名服务器告知该域名的一级域名服务器， 然后本地服务器给该一级域名服务器发送查询请求， 然后依次类推直到查询到该域名的 IP 地址。 DNS 服务器是基于 UDP 的，使用端口号53。
参考文献
行行复重重 – 互联网协议基础知识
程序员小灰 – 什么是TCP/IP协议？
牛客校招面试题