计算机网络

安全

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

    1. ession和cookie的区别
      参考 http://www.cnblogs.com/shiyangxt/archive/2008/10/07/1305506.html
    2. HTTP请求中Session实现原理
      参考 http://blog.youkuaiyun.com/zhq426/article/details/2992488
    3. redirect与forward区别
      参考 http://www.cnblogs.com/wxgblogs/p/5602849.html
    4. DNS原理及其解析过程
      参考 http://369369.blog.51cto.com/319630/812889/
    1. DDos攻击及预防
      参考 http://blog.youkuaiyun.com/huwei2003/article/details/45476743 
      http://www.leiphone.com/news/201509/9zGlIDvLhwguqOtg.html
    2. 如果客户端不断的发送请求连接会怎样
      参考 http://blog.youkuaiyun.com/edward30/article/details/8661105
    3. 那怎么知道连接是恶意的呢?可能是正常连接
      参考 http://blog.youkuaiyun.com/caomiao2006/article/details/51408252
    •  
    • 现在你实验室有一台笔记本,ip为192.168.1.135,然后你从浏览器输入baidu.com,你说说整个过程发生了什么?我们再单单看从应用层,依次往下发生了什么,说说每一层的包会封装什么内容?IP层的包头大小为多少呢?现在你有百度的服务器IP了,你说说你的网络包是如何从内网传输到该地址的,比如包经过交换机,路由器等会查路由表和选定端口,你来说说详细过程是怎么的?你说到了网关,为什么需要网关呢?
    •  
    • 两台电脑连接同一台路由器,然后登陆牛客网,牛客网将登陆成功的信息返回给两台电脑。  问,牛客网是如何正确返回信息到两台电脑上的,流程是什么,经历了什么? 
    • 答:NAT的基本工作原理是,当私有网主机和公共网主机通信的IP包经过NAT网关时,将IP包中的源IP或目的IP在私有IP和NAT的公共IP之间进行转换。
    •  
    • html怎么绘制的?
    •  
    •  
    • cookie和session的请求?
    • cookie和session区别?
    • 分布式session怎么实现,提供几种方案?
    •  
      • 序列化 意义、特性、方法、方法区别。
      • BIO NIO 几个组件 
      • DNS解析的域名,你直接去ping,能成功吗,它是一个web server吗
      • ARP协议有没有了解过?如何防御ARP欺骗?
    • 常见协议的端口号
      • 计算机网络体系结构
    • 五层协议
    • 应用层:为特定应用程序提供数据传输服务,例如 HTTP、DNS 等。数据单位为报文。 
    • 运输层:为进程提供通用数据传输服务。由于应用层协议很多,定义通用的运输层协议就可以支持不断增多的应用层协议。运输层包括两种协议:传输控制协议 TCP,提供面向连接、可靠的数据传输服务,数据单位为报文段;用户数据报协议 UDP,提供无连接、尽最大努力的数据传输服务,数据单位为用户数据报。TCP 主要提供完整性服务,UDP 主要提 供及时性服务。 
    • 网络层:为主机提供数据传输服务。而运输层协议是为主机中的进程提供数据传输服务。 网络层把运输层传递下来的报文段或者用户数据报封装成分组。 
    • 数据链路层:网络层针对的还是主机之间的数据传输服务,而主机之间可以有很多链路, 链路层协议就是为同一链路的主机提供数据传输服务。数据链路层把网络层传下来的分组封装成帧。 
    • 物理层:考虑的是怎样在传输媒体上传输数据比特流,而不是指具体的传输媒体。物理层的作用是尽可能屏蔽传输媒体和通信手段的差异,使数据链路层感觉不到这些差异。
    • OSI 
    • 表示层:数据压缩、加密以及数据描述,这使得应用程序不必关心在各台主机中数据内部 格式不同的问题。 
    • 会话层:建立及管理会话。 五层协议没有表示层和会话层,而是将这些功能留给应用程序开发者处理。 
    • TCP/IP 
    • 不严格遵循 OSI 分层概念,应用层可能会直接使用 IP 层或者网络接口层。 
    • TCP/IP 协议族是一种沙漏形状,中间小两边大,IP 协议在其中占用举足轻重的地位。 (everything is over ip)
    • tcp/ip四层协议,每层有哪些具体的协议,还问了几个协议的端口号
    • Gossip协议下面又是什么协议呢
    • TCP/IP
    • 网线断了,tcp连接情况
    • TCP包有没有IP地址?
    • TCP和UDP的区别、具体应用场景。如果想发送即时消息应该用哪种协议
    • 三次握手和四次挥手
    • 三次握手
    1. TCP服务器进程先创建【传输控制块TCB】,时刻准备接受客户进程的连接请求,此时服务器就进入了LISTEN(监听)状态;
    2. 客户端进程先创建【传输控制块TCB】,然后向服务器发出连接请求报文段,首部中同步位SYN置为1,同时选择一个初始序列号 seq=x 。此时,TCP客户端进程进入了 SYN_SENT(同步已发送状态)状态。
    3. 服务器收到请求报文后,如果同意连接,则发出确认报文,在确认报文段中将SYN位和ACK位置1,确认号ack=x+1(客户端初始序列号+1),同时发送自己的初始化序列号seq=y。此时,TCP服务器进程进入了SYN_RCVD(同步收到)状态。
    4. 客户进程收到确认后,还要向服务器给出确认。确认报文段的ACK置1,确认号ack=y+1,自己的序列号seq=x+1。此时,TCP连接建立,客户端进入ESTABLISHED(已建立连接)状态。
    5. 当服务器收到客户端的确认后也进入ESTABLISHED状态,此后双方就可以开始通信了。
    • 规定:
    • SYN报文段(SYN=1的报文段)不能携带数据,但需要消耗掉一个序号,这样每发送一个SYN,序列号就会自动+1,这样如果出现丢失的情况,该SYN段会重传。
    • ACK报文段可以携带数据,但是如果不携带数据则不消耗序号。
    • FIN报文段即使不携带数据,也要消耗一个序号。
    • 四次挥手
    1. 客户端发出连接释放报文,并且停止发送数据。把连接释放报文段首部的终止控制位FIN置1,其序列号seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1)。客户端进入FIN_WAIT_1(终止等待1)状态,等待服务器确认。
    2. 服务器收到连接释放报文,发出确认报文,确认号ack=u+1,以及自己的序列号seq=v(等于服务器前面已经传送的数据的最后一个字节的序号+1)。然后服务端进入了CLOSE_WAIT(关闭等待)状态。TCP服务器通知高层的应用进程,客户端向服务器方向的连接释放,这时的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(两倍最长报文段寿命)的时间没问题后,才进入CLOSED状态。
    6. 服务器只要收到了客户端发出的确认,立即进入CLOSED状态。
    • 为什么三次握手
      • 为了防止已经失效的连接请求报文突然又传送到了服务器,从而产生错误。
      • 如果使用的是两次握手建立连接,假设有这样一种场景:客户端发送了第一个请求连接并且没有丢失,只是在网络结点中滞留的时间太长了。因此TCP的客户端迟迟没有收到确认报文,以为服务器没有收到,重新向服务器发送这条报文,顺利到达。之后客户端和服务器经过两次握手完成连接,传输数据,然后关闭连接。但是此时,之前滞留的那一次请求连接,突然网络通畅了到达了服务器。这个报文本该是失效的,但是,两次握手的机制将会让客户端和服务器再次建立连接,这将导致不必要的错误和资源的浪费。如果采用的是三次握手,就算是那一次失效的报文传送到了服务端,服务端也回复了确认报文,但是由于客户端不想建立连接了,不会再次发出确认。那么服务器收不到确认,就知道客户端并没有请求连接。
      • 问题本质是信道不可靠,但是通信双发需要就某个问题达成一致。要解决这个问题,三次通信是理论上的最小值。所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的。
    • 为什么四次挥手,为什么断开的时候ACK和FIN是分开发的
      • 因为在确认收到客户端的FIN,到服务端close之间,服务端可能还有数据需要传送给客户端。(客户端处于半开状态,不可以发送,但可以接收)。
      • 当主机1发出FIN报文段时,只是表示主机1已经没有数据要发送了,主机1告诉主机2,它的数据已经全部发送完毕了;但是,这个时候主机1还是可以接受来自主机2的数据;当主机2返回ACK报文段时,表示它已经知道主机1没有数据发送了,但是主机2还是可以发送数据到主机1的;当主机2也发送了FIN报文段时,这个时候就表示主机2也没有数据要发送了,就会告诉主机1,我也没有数据要发送了,彼此就中断这次TCP连接。
    • TIME_WAIT为什么至少设置两倍的MSL时间?
      1. 为了保证客户端发送的最后一个ACK报文段能够到达服务器。最后一个ACK有可能丢失,因而使处于LAST_ACK状态的服务器收不到之前客户端对自己发送的FIN+ACK报文段的确认。服务器会超时重传这个FIN+ACK报文段,这样客户端就能在2MSL的时间内收到重传,并且重传一次确认,重置2MSL计时器。如果客户端不等待,而最后一条ACK丢失,服务器收不到就会一直等待,就无法正常进入closed状态。
      2. 为了防止“已失效的连接请求报文段”出现在本连接中。客户端发送完最后一个ACK,再经过2MS时间,可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新连接中不会出现旧的连接请求报文段。
    • TCP可靠性
      • 原理:
        • 停止等待协议:每发送完一个分组(数据单元)就停止发送,等待对方确认。在收到确认后再发送下一个分组。
        • 连续AQR协议:滑动窗口协议
      • 实现:
        1. 以字节为单位的滑动窗口
          • 窗口是缓存的一部分,用来暂时存放字节流。发送方和接收方各有一个窗口,接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小,发送方根据这个值和其它信息设置自己的窗口大小。 
          • 发送窗口内的字节都允许被发送,接收窗口内的字节都允许被接收。如果发送窗口左部的字节 已经发送并且收到了确认,那么就将发送窗口向右滑动一定距离,直到左部第一个字节不是已发送并且已确认的状态;接收窗口的滑动类似,接收窗口左部字节已经发送确认并交付主机, 就向右滑动接收窗口。 
          • 接收窗口只会对窗口内最后一个按序到达的字节进行确认,例如接收窗口已经收到的字节为 {31, 34, 35},其中 {31} 按序到达,而 {34, 35} 就不是,因此只对字节 31 进行确认。发送方得到一个字节的确认之后,就知道这个字节之前的所有字节都已经被接收。 
        2. 超时重传时间的选择:如果超过一定时间仍然没有收到确认,就认为刚才发送的分组丢失了,进行重传。
          • 具体:每发送完一个分组时设置一个超时计时器,时间比数据在分组传播的平均往返时间更长一些。
          • 发送完一个分组之后必须暂时保留已发送分组的副本,收到确认后删除
          • 分组和确认分组都必须进行编号
        1. 选择确定SACK:收到的报文未按序号,中间缺了一段,可以开启“允许SACK”,在TCP首部字段告知A哪一段没收到。
    • TCP保证信息顺序
      • A发送数据时,TCP给每个数据包分配一个序列号,并且等待B对这个序列号进行确认,如果A在一个特定时间内没有收到B的确认,则A会重传此数据包。B利用序列号对接收的数据进行确认,以便检测A发送的数据是否有丢失或者乱序等,B一旦收到已经顺序化的数据,它就将这些数据按正确的顺序重组成数据流并传递到高层进行处理。
    • TCP流量控制
      • 通过滑动窗口机制控制。
      • 流量控制是为了控制A发送速率,保证B来得及接收。
      • B发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响A的发送速率。将窗口字段设置为 0,则发送方不能发送数据。 
    • TCP拥塞控制
      • 如果网络出现拥塞,分组将会丢失,此时发送方会继续重传,从而导致网络拥塞程度更高。因此当出现拥塞时,应当控制发送方的速率。这一点和流量控制很像,但是出发点不同。流量控制是端对端的,为了让接收方能来得及接收,而拥塞控制是为了降低整个网络的拥塞程度。
    • TCP主要通过四个算法进行拥塞控制:慢开始、拥塞避免、快重传、快恢复。 
    • 发送方需要维护一个叫做拥塞窗口(cwnd)的状态变量。拥塞窗口与发送方窗口的区别:拥塞窗口只是一个状态变量,实际决定发送方能发送多少数据的是发送方窗口。
    • 慢开始与拥塞避免 
    • 发送的最初执行慢开始,令 cwnd = 1,发送方只能发送 1 个报文段;当收到确认后,将 cwnd 加倍,因此之后发送方能够发送的报文段数量为2、4、8 ... 
    • 注意到慢开始每个轮次都将 cwnd 加倍,这样会让 cwnd 增长速度非常快,从而使得发送方发送的速度增长速度过快,网络拥塞的可能性也就更高。因此设置一个慢开始门限 ssthresh,当 cwnd >= ssthresh 时,进入拥塞避免,每个轮次只将 cwnd 加 1。 
    • 如果出现了超时,则令 ssthresh = cwnd / 2,然后重新执行慢开始。 
    • 快重传与快恢复 
    • 在接收方,要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2,此时收到 M4,应当发送对 M2 的确认。 
    • 在发送方,如果收到三个重复确认,那么可以知道被重复确认的报文段的下一个报文段丢失,此时执行快重传,立即重传下一个报文段。例如收到三个 M2,则 M3 丢失,立即重传 M3。 
    • 在这种情况下,只是丢失个别报文段,而不是网络拥塞。因此执行快恢复,令 ssthresh = cwnd / 2 ,cwnd = ssthresh,此时直接进入拥塞避免。 
    • 慢开始和快恢复的快慢指的是 cwnd 的设定值,而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1,而快恢复 cwnd 设定为 ssthresh。 
    • TCP拆包粘包
      • TCP是个“流”协议,所谓流,就是没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义,它会根据TCP缓冲区的实际情况进行包的划分,所以在业务上认为,一个完整的包可能会被TCP拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这就是所谓的TCP粘包和拆包问题。
    • 拆包粘包表现形式:
    • 假设客户端分别发送了两个数据包D1和D2给服务端,由于服务端一次读取到的字节数是不确定的,故可能存在以下4种情况。
      1. 服务端分两次读取到了两个独立的数据包,分别是D1和D2,没有粘包和拆包;
      2. 服务端一次接收到了两个数据包,D1和D2粘合在一起,被称为TCP粘包;
      3. 服务端分两次读取到了两个数据包,第一次读取到了完整的D1包和D2包的部分内容,第二次读取到了D2包的剩余内容,这被称为TCP拆包;
      4. 服务端分两次读取到了两个数据包,第一次读取到了D1包的部分内容D1_1,第二次读取到了D1包的剩余内容D1_2和D2包的整包。
      • 如果此时服务端TCP接收滑窗非常小,而数据包D1和D2比较大,很有可能会发生第五种可能,即服务端分多次才能将D1和D2包接收完全,期间发生多次拆包。
    • 粘包、拆包发生原因:
      1. 要发送的数据大于TCP发送缓冲区剩余空间大小,将会发生拆包。
      2. 待发送数据大于MSS(最大报文长度),TCP在传输前将进行拆包。
      3. 要发送的数据小于TCP发送缓冲区的大小,TCP将多次写入缓冲区的数据一次发送出去,将会发生粘包。
      4. 接收数据端的应用层没有及时读取接收缓冲区中的数据,将发生粘包。
    • 粘包、拆包解决办法:
      1. 发送端给每个数据包添加包首部,首部中应该至少包含数据包的长度,这样接收端在接收到数据后,通过读取包首部的长度字段,便知道每一个数据包的实际长度了。
      2. 发送端将每个数据包封装为固定长度(不够的可以通过补0填充),这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。
      3. 可以在数据包之间设置边界,如添加特殊符号,这样,接收端通过这个边界就可以将不同的数据包拆分开。
    • TCP 包为什么需要 Seq
    • IP协议
    • IP协议是什么,#TCP和IP协议的区别
      • 网际协议,网络之间的互连协议,用来使互联起来的许多计算机能够进行通信。
      • 因为网络层是整个互联网的核心,因此应当让网络层尽可能简单。网络层向上只提供简单灵活的、无连接的、尽最大努力交互的数据报服务。
      • 使用 IP 协议,可以把异构的物理网络连接起来,使得在网络层看起来好像是一个统一的网 络。 
      • IP协议在网络层,TCP协议在运输层。IP协议管网络之间传送数据,TCP协议管进程之间传送数据。IP协议面向无连接,不可靠,TCP协议面向连接,可靠。
    • 子网掩码
    • 子网掩码的组成
      • 同IP地址一样,子网掩码是由长度为32位二进制数组成的一个地址。
      • 子网掩码32位与IP地址32位相对应,IP地址如果某位是网络地址,则子网掩码为1,否则为0。如:11111111.11111111.11111111.00000000
    • 子网掩码的表示方法
    1. 点分十进制表示法
      • 二进制转换十进制,每8位用点号隔开
      • 例如:子网掩码二进制11111111.11111111.11111111.00000000,表示为255.255.255.0
    2. CIDR斜线记法【常用】
      • IP地址/n(表示掩码二进制有几个1)
      • 例:172.16.198.12/20。其子网掩码表示为255.255.240.0,二进制表示为11111111.11111111.11110000.00000000
    • 为什么要使用子网掩码
      • 子网掩码可以分离出IP地址中的网络地址和主机地址。两台主机要通信,首先要判断是否处于同一网段,即网络地址是否相同。如果相同,那么可以把数据包直接发送到目标主机,否则就需要路由网关将数据包转发送到目的地。
    • 子网掩码的分类【ip地址编址方式】
      • 缺省子网掩码:
        • 也叫默认子网掩码,即未划分子网,对应的网络号的位都置 1 ,主机号都置 0 。
        • 未做子网划分的IP地址:网络号+主机号
        • A类网络缺省子网掩码: 255.0.0.0,用CIDR表示为/8
        • B类网络缺省子网掩码: 255.255.0.0,用CIDR表示为/16
        • C类网络缺省子网掩码: 255.255.255.0,用CIDR表示为/24
      • 自定义子网掩码
        • 将一个网络划分子网后,把原本的主机号位置的一部分给了子网号,余下的才是给了子网的主机号。做子网划分后的IP地址:网络号+子网号+子网主机号
        • 如:192.168.1.100/25,其子网掩码表示:255.255.255.128
        • 意思就是将192.168.1.0这个网段的主机位的最高1位划分为了子网。
    • 地址解析协议 ARP 
      • 网络层实现主机之间的通信,而链路层实现具体每段链路之间的通信。因此在通信过程中,IP 数据报的源地址和目的地址始终不变,而 MAC 地址随着链路的改变而改变。 
      • ARP 实现由 IP 地址得到 MAC 地址。 
      • 每个主机都有一个 ARP 高速缓存,里面有本局域网上的各主机和路由器的 IP 地址到 MAC 地址的映射表。 
      • 如果主机 A 知道主机 B 的 IP 地址,但是 ARP 高速缓存中没有该 IP 地址到 MAC 地址的映 射,此时主机 A 通过广播的方式发送 ARP 请求分组,主机 B 收到该请求后会发送 ARP 响应分组给主机 A 告知其 MAC 地址,随后主机 A 向其高速缓存中写入主机 B 的 IP 地址到 MAC 地址的映射。 
    • 网际控制报文协议 ICMP 
      • ICMP 是能够更有效地转发 IP 数据报和提高交付成功的机会。它封装在 IP 数据报中。不属于高层协议。 
      • Ping 
        • Ping 是 ICMP 的一个重要应用,主要用来测试两台主机之间的连通性。 
        • Ping 的原理是通过向目的主机发送 ICMP Echo 请求报文,目的主机收到之后会发送 Echo 回 答报文。Ping 会根据时间和成功响应的次数估算出数据包往返时间以及丢包率。 
      • Traceroute 
        • Traceroute 是 ICMP 的另一个应用,用来跟踪一个分组从源点到终点的路径。 
        • Traceroute 发送的 IP 数据报封装的是无法交付的 UDP 用户数据报,并由目的主机发送终点 不可达差错报告报文。
    • 虚拟专用网 VPN 
      • 由于 IP 地址的紧缺,一个机构能申请到的 IP 地址数往往远小于本机构所拥有的主机数。并且 一个机构并不需要把所有的主机接入到外部的互联网中,机构内的计算机可以使用仅在本机构 有效的 IP 地址(专用地址)。 
      • 有三个专用地址块: 
      • 10.0.0.0 \~ 10.255.255.255 172.16.0.0 \~ 172.31.255.255 192.168.0.0 \~ 192.168.255.255 
      • VPN 使用公用的互联网作为本机构各专用网之间的通信载体。专用指机构内的主机只与本机 构内的其它主机通信;虚拟指好像是,而实际上并不是,它有经过公用的互联网。 
    • 网络地址转换 NAT 
      • 专用网内部的主机使用本地 IP 地址又想和互联网上的主机通信时,可以使用 NAT 来将本地 IP 转换为全球 IP。 
      • 在以前,NAT 将本地 IP 和全球 IP 一一对应,这种方式下拥有 n 个全球 IP 地址的专用网内最 多只可以同时有 n 台主机接入互联网。为了更有效地利用全球 IP 地址,现在常用的 NAT 转 换表把运输层的端口号也用上了,使得多个专用网内部的主机共用一个全球 IP 地址。使用端 口号的 NAT 也叫做网络地址与端口转换 NAPT。 
    • 路由器的结构 
      • 路由器从功能上可以划分为:路由选择和分组转发。
      • 分组转发结构由三个部分组成:交换结构、一组输入端口和一组输出端口。
        • 路由器分组转发流程 
        • 从数据报的首部提取目的主机的 IP 地址 D,得到目的网络地址 N。
        • 若 N 就是与此路由器直接相连的某个网络地址,则进行直接交付; 若路由表中有目的地址为 D 的特定主机路由,则把数据报传送给表中所指明的下一跳路由器;
        • 若路由表中有到达网络 N 的路由,则把数据报传送给路由表中所指明的下一跳路由器; 若路由表中有一个默认路由,则把数据报传送给路由表中所指明的默认路由器; 报告转发分组出错。 
    • 255.255.255.0子网下有多少IP地址(2^8)? 多少个主机个数可用?
    • 给定一个ip地址比如221.130.111.109/30,指出这个IP地址的网络号,主机号,以及子网数。这个地址属于那一类ip地址(A,B,C)类。
    • 说说保留的IP字段是哪些,192.xxx它们是哪一类地址
      • 保留IP地址不会被互联网分配的,也不会被路由通过,主要被用在企业机构内部作为局域网地址使用。
      • A类:10.0.0.0-10.255.255.255(长度相当于1个A类IP地址)
      • A类:100.64.0.0-100.127.255.255
      • B类:172.16.0.0-172.31.255.255(长度相当于16个连续的B类IP地址)
      • C类:192.168.0.0-192.168.255.255(长度相当于256个连续的C类IP地址)
    • ip数据包存在的问题?怎么解决

 

 

 

 

客户端发送的 请求报文 第一行为请求行,包含了方法字段。

https://www.cnblogs.com/logsharing/p/8448446.html

 

当前网络请求中,绝大部分使用的是 GET 方法。

 

和 GET 方法一样,但是不返回报文实体主体部分。 主要用于确认 URL 的有效性以及资源更新的日期时间等。

 

POST 主要用来传输数据,而 GET 主要用来获取资源。

 

由于自身不带验证机制,任何人都可以上传文件,因此存在安全性问题,一般不使用该方法。

 

PUT 也可以用于修改资源,但是只能完全替代原始资源,PATCH 允许部分修改。

 

与 PUT 功能相反,并且同样不带验证机制。

 

查询指定的 URL 能够支持的方法。会返回 Allow: GET, POST, HEAD, OPTIONS 这样的内容。

 

使用 SSL(Secure Sockets Layer,安全套接层)和 TLS(Transport Layer Security,传输层安全)协议把通信内容加密后经网络隧道传输。

CONNECT www.example.com:443 HTTP/1.1 

 

服务器会将通信路径返回给客户端。
 

参考 http://www.cnblogs.com/hyddd/archive/2009/03/31/1426026.html 

http://www.jellythink.com/archives/806

 

 

 

 

 

 

 

传输层为TCP协议,网际层为IP 

 

 

    • HTTP
    • 对HTTP了解多少
      • 超文本传送协议HTTP协议定义了浏览器(即万维网客户进程)怎样向万维网服务器请求万维网文档,以及服务器怎样把文档传送给浏览器。从层次角度看,HTTP是面向事务的应用层协议,是万维网上能够可靠地交换文件的重要基础。HTTP使用了TCP作为传输层协议,保证了数据的可靠传输,但本身是无连接的。
      • HTTP的无状态 
      • HTTP协议是无状态的。也就是说,同一个客户第二次访问同一个服务器上的页面时,服务器的响应与第一次被访问时相同(假定现在服务器还没有更新页面),因为服务器并不记得曾经访问过的这个客户,也不记得为这个客户服务过多少次。HTTP的无状态特性简化了服务器的设计,使服务器更容易支持大量并发的HTTP请求。
    • HTTP报文格式  HTTP报文内容
      • 请求报文:客户端到服务器
      • 响应报文:服务器到客户端
      • 分为报文首部和报文主体两部分
    • HTTP 请求头(应该就是上面图中的请求行吧)
    • HTTP状态码,以及相应的排查错误的方式
      • 服务器返回的 响应报文 中第一行为状态行,包含了状态码以及原因短语,用来告知客户端请 求的结果。 
    • 1XX 信息 
      • 100 Continue:表明到目前为止都很正常,客户端可以继续发送请求或者忽略这个响 应。 
    • 2XX 成功 
      • 200 OK
      • 204 No Content :请求已经成功处理,但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息,而不需要返回数据时使用。 
      • 206 Partial Content :表示客户端进行了范围请求,响应报文包含由 Content-Range 指定范围的实体内容。 
    • 3XX 重定向 
      • 301 Moved Permanently :永久性重定向 
      • 302 Found :临时性重定向 
      • 303 See Other :和 302 有着相同的功能,但是 303 明确要求客户端应该采用 GET 方法 获取资源。 
      • 注:虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法,但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。 
      • 304 Not Modified :如果请求报文首部包含一些条件,例如:If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,如果不满足条件,则服务器会返回 304 状态码。 
      • 307 Temporary Redirect :临时重定向,与 302 的含义类似,但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。 
    • 4XX 客户端错误
      • 400 Bad Request :请求报文中存在语法错误。 
      • 401 Unauthorized :该状态码表示发送的请求需要有认证信息(BASIC 认证、DIGEST 认证)。如果之前已进行过一次请求,则表示用户认证失败。 
      • 403 Forbidden :请求被拒绝。
      • 404 Not Found 
    • 5XX 服务器错误
      • 500 Internal Server Error :服务器正在执行请求时发生错误。 
      • 503 Service Unavailable :服务器暂时处于超负载或正在进行停机维护,现在无法处理 请求。 
    • HTTP方法及相互区别(这边是要web编程的!!!)
    • get和post请求的区别?
    • GET 获取资源 
    • HEAD 获取报文首部 
    • POST 传输实体主体 
    • PUT 上传文件 
    • PATCH 对资源进行部分修改 
    • DELETE 删除文件 
    • OPTIONS 查询支持的方法 
    • CONNECT 要求在与代理服务器通信时建立隧道
    • TRACE 追踪路径 
    • 为什么rpc使用http,和直接http有什么区别
    • get提交和post提交的区别
    • HTTP vs HTTPS 
      • HTTPS协议需要到CA申请证书,一般免费证书很少,需要交费。
      • HTTPS可以有效的防止运营商劫持,解决了防劫持的一个大问题。
      • HTTP协议运行在TCP之上,所有传输的内容都是明文,HTTPS运行在SSL/TLS之上,SSL/TLS运行在TCP之上,所有传输的内容都经过加密的。
      • HTTP和HTTPS使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。
    • 安全性
    • HTTP 本身是明文传输的,没有经过任何安全处理。例如用户在百度搜索了一个关键字,比如“苹果手机”,中间者完全能够查看到这个信息。(这里提到的中间者主要指一些网络节点,是用户数据在浏览器和百度服务器中间传输必须要经过的节点。比如 WIFI 热点,路由器,防火墙,反向代理,缓存服务器等。)在 HTTP 协议下,中间者可以随意嗅探用户搜索内容,窃取隐私甚至篡改网页。 
    • 所以,就有了HTTPS,使用 HTTPS 协议主要是为了保护用户隐私,防止流量劫持。
    • HTTPS的特点
    1. 内容加密。浏览器到百度服务器的内容都是以加密形式传输,中间者无法直接查看原始内容。
    2. 身份认证。保证用户访问的是百度服务,即使被 DNS 劫持到了第三方站点,也会提醒用户没有访问百度服务,有可能被劫持
    3. 数据完整性。防止内容被第三方冒充或者篡改。
    • HTTPS原理
    1. 客户端发起一个https的请求,把自身支持的一系列Cipher Suite(密钥算法套件,简称Cipher)发送给服务端。
    2. 服务端存在一个公匙和私匙。
    3. 服务端,接收到客户端所有的Cipher后与自身支持的对比,如果不支持则连接断开,反之则会从中选出一种加密算法和HASH算法以证书的形式返回给客户端 证书中还包含了 公钥 颁证机构 网址 失效日期等等。
    4. 客户端收到服务端响应后会做以下几件事
      1. 验证证书的合法性:颁发证书的机构是否合法与是否过期,证书中包含的网站地址是否与正在访问的地址一致等,证书验证通过后,在浏览器的地址栏会加上一把小锁(每家浏览器验证通过后的提示不一样 不做讨论(官网:www.fhadmin.org))。
      2. 生成随机密码:如果证书验证通过,或者用户接受了不授信的证书,此时浏览器会生成一串随机数,然后用证书中的公钥加密。 
      3. HASH握手信息:用最开始约定好的HASH方式,把握手消息取HASH值,然后用随机数加密 “握手消息+握手消息HASH值(签名)”  并一起发送给服务端。在这里之所以要取握手消息的HASH值,主要是把握手消息做一个签名,用于验证握手消息在传输过程中没有被篡改过。
    5. 客户端将加密后的内容传给服务端
    6. 服务端拿到客户端传来的密文,用自己的私钥来解密握手消息取出随机数密码,再用随机数密码 解密 握手消息与HASH值,并与传过来的HASH值做对比确认是否一致。
    7. 然后用随机密码加密一段握手消息(握手消息+握手消息的HASH值 )给客户端。
    8. 客户端用随机数解密并计算握手消息的HASH,如果与服务端发来的HASH一致,此时握手过程结束,之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。因为这串密钥只有客户端和服务端知道,所以即使中间请求被拦截也是没法解密数据的,以此保证了通信的安全。
    • TCP、http、socket的区别
      • TCP是传输层协议,定义数据传输和连接方式的规范。握手过程中传送的包里不包含数据,三次握手完毕后,客户端与服务器才正式开始传送数据。
      • HTTP 超文本传送协议是应用层协议,定义的是传输数据的内容的规范。
      • HTTP协议中的数据是利用TCP协议传输的,在TCP连接建立后再通过HTTP协议传送数据。特点是客户端发送的每次请求都需要服务器回送响应,HTTP是TCP协议族中的一种,默认使用 TCP 80端口。
      • 好比网络是路,TCP是跑在路上的车,HTTP是车上的人。
    • http的服务器端和客户端能双向通信吗
      • 不能 至于为什么。。?
    • HTTP 1.0 vs 1.1 vs 2.0 
    • http1.0 vs http1.1
      • 缓存处理
        • 在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准,HTTP1.1则引入了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
        • 带宽优化及网络连接的使用
        • HTTP1.0中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能,HTTP1.1则在请求头引入了range头域,它允许只请求资源的某个部分,即返回码是206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。
      • 错误通知的管理
        • 在HTTP1.1中新增了24个错误状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除。
      • Host头处理
        • 在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。
      • 长连接
        • HTTP 1.1支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟,在HTTP1.1中默认开启Connection: keep-alive,一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
      • 分块编码
        • 分块编码就是把数据拆分成一个个的数据块。
        • 通常情况下,http响应消息以message body的形式作为整包发送给客户端的,用content-length表示消息体的长度,这个长度对于客户端来说非常重要,因为持久连接不会马上结束,而是可以发送多次请求/响应,客户端需要知道哪个位置才是响应消息的结束,以及后续响应的开始,因此这个content-length就显得尤为重要,服务端必须精确地告诉客户端这个值,如果content-length比实际长度短,就会出现截断,如果比实际长度长,就可能出现一直处于pending状态。
        • 在这种情况下,在复杂页面中可能就会出现这样的情况,如果是要把消息完全创建好之后再计算出其content-length,这时候客户端就会有一段等待时间,页面越复杂数据越复杂计算时间越长,可能用户就会受不了。
        • 分块传输编码就是针对这个情况作出的一种解决方案。它将数据分解成一系列数据块,并以多个块发送给客户端,服务器发送数据时不再需要预先告诉客户端发送内容的总大小,只需在响应头里添加Transfer-Encoding:chunk就可以不用告诉客户端发送内容的长度了
    • HTTP2.0
      • http2.0的主要目的是改进传输性能,实现低延迟和高吞吐量。
      • 为什么会需要http2.0?
      • 在http1.1中出现了很多优化措施,但是,当我们想要进行这些措施时,就会发现,其实其中包含了很多限制。HTTP1.x只能串行地返回响应,他不允许一个连接上的多个响应数据交错到达(多路复用),因而一个响应必须完全响应返回之后,下一个响应才回开始传输。
      • 而http2.0就是通过支持请求与响应的多路复用来减少延迟,通过压缩HTTP首部字段来将协议开销降至最低,同时增加对请求优先级和服务器推送的支持
    • HTTP底层协作协议
    • Socket
    • RPC协议(经常和Dubbo一起问)
    • 异步IO多路复用:select poll epoll
    • ARP协议有没有了解过?如何防御ARP欺骗?
    • 安全
    • 加密算法 
    • 对称加密:DES
      • 加密和解密使用相同密钥的加密算法。DES加密算法是一种分组密码,以64位为分组对数据加密,它的密钥长度是56位,加密解密用同一算法。DES加密算法是对密钥进行保密,而公开算法,包括加密和解密算法。这样,只有掌握了和发送方相同密钥的人才能解读由DES加密算法加密的密文数据。因此,破译DES加密算法实际上就是搜索密钥的编码。对于56位长度的密钥来说,如果用穷举法来进行搜索的话,其运算次数为256。
      • 随着计算机系统能力的不断发展,DES的安全性比它刚出现时会弱得多,然而从非关键性质的实际出发,仍可以认为它是足够的。不过,DES现在仅用于旧系统的鉴定,而更多地选择新的加密标准。
    • 非对称加密:RSA
      • 指加密和解密使用不同密钥的加密算法,也称为公私钥加密。假设两个用户要加密交换数据,双方交换公钥,使用时一方用对方的公钥加密,另一方即可用自己的私钥解密。如果企业中有n个用户,企业需要生成n对密钥,并分发n个公钥。由于公钥是可以公开的,用户只要保管好自己的私钥即可,因此加密密钥的分发将变得十分简单。同时,由于每个用户的私钥是唯一的,其他用户除了可以可以通过信息发送者的公钥来验证信息的来源是否真实,还可以确保发送者无法否认曾发送过该信息。非对称加密的缺点是加解密速度要远远慢于对称加密,在某些极端情况下,甚至能比非对称加密慢上1000倍。
    • 详述如何提升数据包在网络中的安全传输 安全性可靠性等问题

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值