Skip to content

Latest commit

 

History

History
executable file
·
354 lines (190 loc) · 25.4 KB

其它.md

File metadata and controls

executable file
·
354 lines (190 loc) · 25.4 KB
Raw

[TOC]

其它

TCP与UDP的区别

UDP 与 TCP 的主要区别在于 UDP 不一定提供可靠的数据传输，它不能保证数据准确无误地到达，不过UDP在许多方面非常有效。当程序是要尽快地传输尽可能多的信息时，可以使用 UDP。TCP它是通过三次握手建立的连接，它在两个服务之间始终保持一个连接状态，目的就是为了提供可靠的数据传输。许多程序使用单独的TCP连接和单独的UDP连接，比如重要的状态信息用可靠的TCP连接发送，而主数据流通过UDP发送。

TCP与UDP区别总结：

1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接

2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付

3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的

UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）

4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信

5、TCP首部开销20字节;UDP的首部开销小，只有8个字节 6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

一般面试官都会问TCP和UDP的区别，这个很好回答啊，TCP面向连接，可靠，基于字节流，而UDP不面向连接，不可靠，基于数据报。对于连接而言呢，其实真正的就不存在，TCP面向连接只不过三次握手在客户端和服务端之间初始化好了序列号。只要满足TCP的四元组+序列号，那客户端和服务端之间发送的消息就有效，可以正常接收。虽然说TCP可靠，但是可靠的背后却是lol无尽之刃的复杂和痛苦，滑动窗口，拥塞避免，四个超时定时器，还有什么慢启动啊，快恢复，快重传啊这里推荐大家看看（图解TCP/IP,这个简单容易，TCP卷123，大量的文字描述真是烦），所以什么都是相对呢，可靠性的实现也让TCP变的复杂，在网络的状况很差的时候，TCP的优势会变成。基于字节流什么意思呢？一句话就可以说明白，对于读写没有相对应的次数。UDP基于数据报就是每对应一个发，就要对应一个收。而TCP无所谓啊，现在应该懂了吧。对于UDP而言，不面向连接，不可靠，没有三次握手，我给你发送数据之前，不需要知道你在不在，不要你的同意，我只管把数据发送出去至于你收到不收到，从来和我没有半毛钱的关系。

对于可靠不可靠而言，没有绝对的说法，TCP可靠仅仅是在传输层实现了可靠，我也可以让UDP可靠啊，那么就要向上封装，在应该层实现可靠性。因此很多公司都不是直接用TCP和UDP，都是经过封装，满足业务的需要而已。说到这里的话，那就在提一下心跳包，在linux下有keep-alive系统自带的，但是默认时间很长，如果让想使用话可以setsockopt设置，我也可以在应用层实现一个简单心跳包，上次自己多开了一个线程来处理，还是包头解决。

上面解释完这个之后面试官可能问，那什么时候用TCP，什么时候用UDP呢？就是问应用场景，所以简历上的知识点自己应该提前做好准备应用场景，知识就是要用在显示场景中，废话真多。不管用TCP和UDP，应用只要看需求，对于TCP更加注重的是可靠性，而不是实时性，如果我发送的数据很重要一点也不能出错，有延迟无所谓的话，那就TCP啊。UDP更加注重是速度快，也就是实时性，对于可靠性要求不那么高，所以像斗鱼，熊猫这些在线直播网站应该在UDP基础是封装了其他协议，比如视频实时传输协议。而且UDP的支持多播，那就很符合这些直播网站了，有时候看直播视频卡顿，人飘逸那可能就是丢包了，但是你也只能往下看。

参考资料

TCP三次握手

因为TCP是一个双向通讯协议，所以要三次握手才能建立：

第一次握手是客户端向服务端发送连接请求包（SYN=J），服务端接收到之后会给客户端发个确认标志（也就是两个包，一个是确认包ACK=J+1,另一个是连接询问请求包SYN=K)，这是第二次握手。第三次握手就是客户端会再次给服务端发送消息确认标志ACK=K+1，表示能正常接收可以开始通信。第三次握手的目的是为了防止已经失效的连接请求突然又传送到了服务端，因为网络中有可能存在延迟的问题，如果采用二次握手就会让服务端误认为client是再次发出新的连接请求，然后server一直等待client发来数据，这样就浪费了很多资源。这三次握手是在connect,bind,listen和accept函数中完成的，这几个函数创建了比较可靠的连接通道。其实断开连接的四次握手是跟连接的时候一样的，唯一多了一步就是因为双方都处在连接的时候，而且有可能在传输数据，在服务端接收到客户端的关闭连接请求后它会给客户端确认，但是由于数据还没有传送完毕，此时会进入一个TIME_WAIT状态，所以在数据传送好之后会再次给客户端发消息，这就是多出来的那一步。

过程：

第一次

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

此时客户端状态为：SYN_SENT，服务器为LISTEN。

第二次

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

此时客户端状态为ESTABLISHED，服务器为SYS_RCVD

第三次

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

此时客户端和服务器的状态都为ESTABLISHED。

完成三次握手，客户端与服务器开始传送数据。

必要性：

考虑一次的问题，首先tcp是面向连接，一次握手肯定建立不了连接，因为客户机给服务器发出请求信息却没有得到回应，客户机是没法判定是否发送成功然后建立连接的。

再看两次，假设只有两次握手，比如图中的1，2步，当A想要建立连接时发送一个SYN，然后等待ACK，结果这个SYN因为网络问题没有及时到达B，所以A在一段时间内没收到ACK后，再发送一个SYN，这次B顺利收到，接着A也收到ACK，这时A发送的第一个SYN终于到了B，对于B来说这是一个新连接请求，然后B又为这个连接申请资源，返回ACK，然而这个SYN是个无效的请求，A收到这个SYN的ACK后也并不会理会它，而B却不知道，B会一直为这个连接维持着资源，造成资源的浪费。

两次握手的问题在于服务器端不知道一个SYN是否是无效的，而三次握手机制因为客户端会给服务器回复第二次握手，也意味着服务器会等待客户端的第三次握手，如果第三次握手迟迟不来，服务器便会认为这个SYN是无效的，释放相关资源。但这时有个问题就是客户端完成第二次握手便认为连接已建立，而第三次握手可能在传输中丢失，服务端会认为连接是无效的，这时如果Client端向Server写数据，Server端将以RST包响应，这时便感知到Server的错误。

总之，三次握手可以保证任何一次握手的失败都是可感知的，不会浪费资源

TCP四次挥手

对于一个已经建立的连接，TCP使用改进的三次握手来释放连接（使用一个带有FIN附加标记的报文段）。TCP关闭连接的步骤如下：

第一步，当主机A的应用程序通知TCP数据已经发送完毕时，TCP向主机B发送一个带有FIN附加标记的报文段（FIN表示英文finish）。

第二步，主机B收到这个FIN报文段之后，并不立即用FIN报文段回复主机A，而是先向主机A发送一个确认序号ACK，同时通知自己相应的应用程序：对方要求关闭连接（先发送ACK的目的是为了防止在这段时间内，对方重传FIN报文段）。

第三步，主机B的应用程序告诉TCP：我要彻底的关闭连接，TCP向主机A送一个FIN报文段。

第四步，主机A收到这个FIN报文段后，向主机B发送一个ACK表示连接彻底释放。

四次挥手

形象描述四次挥手：

假设Client端发起中断连接请求，也就是发送FIN报文。Server端接到FIN报文后，意思是说"我Client端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以你先发送ACK，"告诉Client端，你的请求我收到了，但是我还没准备好，请继续你等我的消息"。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，"告诉Client端，好了，我这边数据发完了，准备好关闭连接了"。Client端收到FIN报文后，"就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。“，Server端收到ACK后，"就知道可以断开连接了"。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！

需四次挥手原因：由于TCP的半关闭特性，TCP连接时双全工（即数据在两个方向上能同时传递），因此，每个方向必须单独的进行关闭。这个原则就是：当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向上的连接。当一端收到一个FIN后，它必须通知应用层另一端已经终止了那个方向的数据传送。即收到一个FIN意味着在这一方向上没有数据流动了。

假设客户机A向服务器B请求释放TCP连接，则：

第一次挥手：主机A向主机B发送FIN包；A告诉B，我（A）发送给你（B）的数据大小是N，我发送完毕，请求断开A->B的连接。

第二次挥手：主机B收到了A发送的FIN包，并向主机A发送ACK包；B回答A，是的，我总共收到了你发给我N大小的数据，A->B的连接关闭。

第三次挥手：主机B向主机A发送FIN包；B告诉A，我（B）发送给你（A）的数据大小是M，我发送完毕，请求断开B->A的连接。

第四次挥手：主机A收到了B发送的FIN包，并向主机B发送ACK包；A回答B，是的，我收到了你发送给我的M大小的数据，B->A的连接关闭。

这里再系统性的介绍四次握手

当客户端和服务器通过三次握手建立了TCP连接以后，当数据传送完毕，肯定是要断开TCP连接的啊。那对于TCP的断开连接，这里就有了神秘的“四次挥手”。

  1. 第一次挥手：主机1（可以使客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；
  2. 第二次挥手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我“同意”你的关闭请求；
  3. 第三次挥手：主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST_ACK状态；
  4. 第四次挥手：主机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连接。如果要正确的理解四次分手的原理，就需要了解四次分手过程中的状态变化。

  • FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。（主动方）
  • FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。（主动方）
  • CLOSE_WAIT：这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。（被动方）
  • LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。（被动方）
  • TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FINWAIT1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。（主动方）
  • CLOSED: 表示连接中断。

参考资料

TCP四次挥手最后client端的状态是什么知道吗？

  • TODO

TCP连接的可靠性

TCP通过以下方式提供数据传输的可靠性：

（1）TCP在传输数据之前，都会把要传输的数据分割成TCP认为最合适的报文段大小。在TCP三次我握手的前两次握手中（也就是两个SYN报文段中），通过一个“协商”的方式来告知对方自己期待收到的最大报文段长度（MSS），结果使用通信双发较小的MSS最为最终的MSS。在SYN=1的报文段中，会在报文段的选项部分来指定MSS大小（相当于告知对方自己所能接收的最大报文段长度）。在后续通信双发发送应用层数据之前，如果发送数据超过MSS，会对数据进行分段。

（2）使用了超时重传机制。当发送一个TCP报文段后，发送发就会针对该发送的段启动一个定时器。如果在定时器规定时间内没有收到对该报文段的确认，发送方就认为发送的报文段丢失了要重新发送。

（3）确认机制。当通信双发的某一端收到另一个端发来的一个报文段时，就会返回对该报文段的确认报文。

（4）首部校验和。在TCP报文段首部中有16位的校验和字段，该字段用于校验整个TCP报文段（包括首部和数据部分）。IP数据报的首部校验和只对IP首部进行校验。TCP详细的校验过程如下，发送TCP报文段前求一个值放在校验位，接收端接受到数据后再求一个值，如果两次求值形同则说明传输过程中没有出错；如果两次求值不同，说明传输过程中发生错误，无条件丢弃该报文段引发超时重传。

（5）使用滑动窗口流量控制协议。

（6）由于在TCP发送端可能对数据分段，那么在接收端会对接收到的数据重新排序。

参考：腾讯面试TCP连接相关问题

TCP 面向字节流的体现

  • TODO

UDP 面向报文的体现

  • TODO

ISO的7层网络模型

口诀：应表会传网数物

  • 应用层：处理网络应用
  • 表示层：数据表示
  • 会话层：互连主机通信
  • 传输层：端到端连接
  • 网络层：寻址和最短路径
  • 数字链路层：接入介质
  • 物理层：二进制传输

DNS

DNS（Domain Name System，域名系统），万维网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过域名，最终得到该域名对应的IP地址的过程叫做域名解析（或主机名解析）。DNS协议运行在UDP协议之上，使用端口号53。在RFC文档中RFC 2181对DNS有规范说明，RFC 2136对DNS的动态更新进行说明，RFC 2308对DNS查询的反向缓存进行说明。

DOS

Dos攻击在众多网络攻击技术中是一种简单有效并且具有很大危害性的攻击方法。它通过各种手段消耗网络带宽和系统资源，或者攻击系统缺陷，使正常系统的正常服务陷于瘫痪状态，不能对正常用户进行服务，从而实现拒绝正常用户访问服务。

DDOS攻击是基于DOS攻击的一种特殊形式。攻击者将多台受控制的计算机联合起来向目标计算机发起DOS攻击，它是一种大规模协作的攻击方式，主要瞄准比较大的商业站点，具有较大的破坏性。

如何防止DOS攻击？

  1. 确保服务器的系统文件是最新的版本，并及时更新系统补丁。
  2. 关闭不必要的服务。
  3. 限制同时打开的SYN半连接数目。
  4. 缩短SYN半连接的time out 时间。
  5. 正确设置防火墙 禁止对主机的非开放服务的访问 限制特定IP地址的访问 启用防火墙的防DDoS的属性 严格限制对外开放的服务器的向外访问 运行端口映射程序祸端口扫描程序，要认真检查特权端口和非特权端口。
  6. 认真检查网络设备和主机/服务器系统的日志。只要日志出现漏洞或是时间变更，那这台机器就可 能遭到了攻击。
  7. 限制在防火墙外与网络文件共享。这样会给黑客截取系统文件的机会，主机的信息暴露给黑客，无疑是给了对方入侵的机会。

大小端模式

大端模式，是指数据的高字节保存在内存的低地址中，而数据的低字节保存在内存的高地址中，这样的存储模式有点儿类似于把数据当作字符串顺序处理：地址由小向大增加，而数据从高位往低位放；这和我们的阅读习惯一致。

小端模式，是指数据的高字节保存在内存的高地址中，而数据的低字节保存在内存的低地址中，这种存储模式将地址的高低和数据位权有效地结合起来，高地址部分权值高，低地址部分权值低。

比如现在有一块四个字节的内存，并且地址是从左往右递增的。为了方便，都置为 0

1000:1000 00 00 00 00

现有一个十六进制数 0x12345678，这个十六进制数刚好可以使用上面的那块内存去存放，因为它们都是32bits。

大端序

如果是大端序，内存表现将会是这样

1000:1000 12 34 56 78

可以发现，12 是原十六进制数 0x12345678 的高位，而这个 12 放在上面那块内存地址的最低单元中（因为前面说了，这块内存地址是从左往右递增的，所以左边是相对低位，右边是相对高位）。 这就是这段话的意思

大端模式，是指数据的高字节保存在内存的低地址中，而数据的低字节保存在内存的高地址中

小端序

如果是小端序，内存表现是这样的

1000:1000 78 56 34 12

可以发现，78 是原十六进制数 0x12345678 的低位，而此时它也放在了最低的内存单元中，这就是这段话的意思

小端模式，是指数据的高字节保存在内存的高地址中，而数据的低字节保存在内存的低地址中

另外，可以发现，大小端序对字节内容是没有影响的，12 还是 12 并没有变成 21

参考资料

线程和进程的区别

根本区别：进程是操作系统资源分配的基本单位，而线程是任务调度和执行的基本单位

在开销方面：每个进程都有独立的代码和数据空间（程序上下文），程序之间的切换会有较大的开销；线程可以看做轻量级的进程，同一类线程共享代码和数据空间，每个线程都有自己独立的运行栈和程序计数器（PC），线程之间切换的开销小。

所处环境：在操作系统中能同时运行多个进程（程序）；而在同一个进程（程序）中有多个线程同时执行（通过CPU调度，在每个时间片中只有一个线程执行）

内存分配方面：系统在运行的时候会为每个进程分配不同的内存空间；而对线程而言，除了CPU外，系统不会为线程分配内存（线程所使用的资源来自其所属进程的资源），线程组之间只能共享资源。

包含关系：没有线程的进程可以看做是单线程的，如果一个进程内有多个线程，则执行过程不是一条线的，而是多条线（线程）共同完成的；线程是进程的一部分，所以线程也被称为轻权进程或者轻量级进程。

参考资料

Linux 常见命令

  • TODO

参考资料

操作系统加载流程？

  • TODO

进程与线程的区别和联系？

  • TODO

进程的常见状态？以及各种状态之间的转换条件？

  • TODO

静态链接与动态链接的优缺点？

  • TODO

死锁？死锁产生的条件？预防、避免死锁的方法？

  • TODO

进程间通信的方式？各种方式的区别以及应用场景？

  • TODO

线程同步的方式？各种方式的区别？

TODO

虚拟内存？使用虚拟内存的优点？

TODO

Linux下进程的内存布局？

TODO

页面置换算法？LRU Cache算法？

  • TODO

Linux IO多路复用的机制：select,poll,epoll。三种复用机制的区别与联系？

  • TODO

OSI 7层网络模型中各层的名称及其作用？

  • TODO

TCP/IP 4层网络模型名称及其作用？

  • TODO

OSI 7层网络中各层的常见协议以及协议作用？

TODO

OSI网络模型中工作在各个层次的物理设备以及其作用？

  • TODO

IP层功能？如何用int型变量保存一个IPv4地址？

  • TODO

UDP协议：头信息？使用场景？如何使用UDP建立可靠连接？

  • TODO

http协议：各个版本的区别？http请求头，响应头常用属性？常用状态码及其含义？

  • TODO

socket编程：服务端，客户端建立TCP连接调用那些函数？分别对应什么状态？

  • TODO

Linux 常用网络命令的原理：ping, traceroute

  • TODO

浏览器中点击一个超链接到显示对应页面的全过程？

  • TODO

DNS的作用？什么时候使用TCP? 什么时候使用UDP?

  • TODO

TODO