Skip to content

Other_Question_List.md

Latest commit

 

History

History
41 lines (26 loc) · 3.47 KB

Other_Question_List.md

File metadata and controls

41 lines (26 loc) · 3.47 KB
Raw

Other Question List（Network|Structure）

1.Gradle 的 api 和 implementation 有什么区别

区别就是是否将依赖暴露出去。api 会暴露，implementation 不会。

使用 implementation 时，依赖库变动的话只会影响、重新编译到当前库，不会影响到其他，因此编译速度回提高。

api 依赖的库变动的话，会重新编译所有依赖它的项目，相对编译时间会变长。

2.HTTP 和 HTTPS的区别 以及 HTTPS协议传输数据的具体流程

HTTPS的原理及连接流程

3.HTTP 2.0

  1. HTTP/2采用二进制格式而非文本格式
  2. HTTP/2是完全多路复用的，而非有序并阻塞的——只需一个连接即可实现并行，HTTP2.0使用多路复用技术(Multiplexing),多路复用允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。
  3. 使用报头压缩，HTTP/2降低了开销
  4. HTTP/2让服务器可以将响应主动“推送”到客户端缓存中

4.网络通信相关问题，OSI七层模型，TCP/UDP的区别

5.TCP建立连接的三次握手

通俗大白话来理解TCP协议的三次握手和四次分手

在Google Groups的TopLanguage中看到一帖讨论TCP“三次握手”觉得很有意思。贴主提出“TCP建立连接为什么是三次握手？”的问题，在众多回复中，有一条回复写道：“这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了.”。这可视为对“三次握手”目的的另一种解答思路。

  • 第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；
  • 第二次握手：服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；
  • 第三次握手：客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。 完成了三次握手，客户端和服务器端就可以开始传送数据。以上就是TCP三次握手的总体介绍。

6.提问

  • 你们CodeReview的流程，以及关注的点有哪些？会关注并处理lint检查的结果么？
  • 你们使用Kotlin么？
  • 你们使用Android Architecture Component（JetPack）么？
  • 开发之前，会进行项目结构以及技术选型的讨论和设计么？
  • 业务了解