尝试说明 char *s = ”aaa” 和 char s[]=”aaa”的区别。
- char *s中的s是指针，而指针是指向一块内存区域，它指向的内存区域的大小可以随时改变，而且当指针指向常量字符串时，它的内容是不可以被修改的，否则在运行时会报错。
char s[]中的s是数组首地址，而数组首地址对应着一块内存区域，其地址和容量在生命期里()不会改变，只有数组的内容可以改变。 - 我们可以理解为:char[]是一个数组定义，char*是指针定义.数组是开辟一块连续的内存空间，数组本身的标识符（也就是通常所说的数组名）代表整个数组，可以使用sizeof来获得数组所占据内存空间的大小（注意，不是数组元素的个数，而是数组占据内存空间的大小，这是以字节为单位的）。 char[] 表示s是一个数组指针,不允许对该指针进行修改。但该指针所指向的数组内容，是分配在栈上面的，是可以修改的。
如何理解面向对象编程。
- 面向对象编程，即OOP，是一种编程范式，满足面向对象编程的语言，一般会提供类、封装、继承等语法和概念来辅助我们进行面向对象编程。类型被设计为将数据和行为捆绑在一起的一种东西，数据和行为被称之为类型的成员。我们可以创建类型的实例，不同的实例包含不同的数据，从而其表现出来的行为也会不同，尽管其代码是一样的。封装使得类的成员得以有选择性的暴露，一些成员只在类型的内部使用，被称之为私有的（private），一些成员可以被派生类型使用，称之为受保护的（protected），一些成员可以被任何东西使用，称之为公开的（public）。面向对象编程最初是为了解决GUI程序设计问题所提出的，后来面向对象编程被发现也比较适合用于许多特定领域的开发。面向对象编程是目前运用最为广泛的一种编程范式，从而也产生了非常多的解决代码复用的技巧，其中相当一部分技巧在程序中反复出现而被提炼为设计模式。
- 我理解为:“假设我是女娲，我准备捏一些人， 首先，人应该有哪些基本特征：1.有四肢 2.有大脑 3.有器官 4.有思想 我们就有了第一个模型，这就是抽象(即为有了一个类)。 其次，我和西方上帝是好友，我想我的这个想法能够提供给他用，但是我不想让他知道里面细节是怎么捏出来的，用的什么材料，他也不用考虑那么多，只要告诉我他要捏什么样的人就可以了。这就是封装。然后，我之后创造的人都以刚才的模型做为模板，我创造的人都有我模型的特征 这就是继承。最后，我觉得为了让人更丰富多彩，可以根据模型进行删减，某些人器官不尽相同。这就是多态,即为有了男女的分别。"
- 一句话简单说说:面向过程就是蛋炒饭.面向对象就是盖浇饭.
简述一下Tcp的三次握手与四次挥手。
- 三次握手：
- 第一次握手：客户端发送syn包(syn=x)到服务器，并进入SYN_SEND状态，等待服务器确认；
- 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
- 第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
- 握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。
- 四次挥手:
与建立连接的“三次握手”类似，断开一个TCP连接则需要“四次挥手”。- 第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可以接受数据。
- 第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。
- 第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。
- 第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。
- 简述:
- TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。
- 主动关闭方向被动关闭方发送不会再给你发数据了的信息；被动关闭方对收到的主动关闭方的报文段进行确认；被动关闭方向主动关闭方发送我也不会再给你发数据了的信息；主动关闭方再次对被动关闭方的确认进行确认。
- 为什么要3次握手:
- TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。
- 采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。
- 采用两次握手不行，原因就是上面说的失效的连接请求的特殊情况，因此采用三次握手刚刚好，两次可能出现失效，四次甚至更多次则没必要，反而复杂了。
简述你对OSI七层协议模型和TCP/IP四层模型的理解。
百度出了一张图
- 个人理解:
- 模块是抽象的，比如：把这个当做一个模块进行开发。
- 组件是具体的，比如：这个组件不好用，这个组件太大，这个组件不好看。这些都是具体的，客观的。
对比 Ajax 与 Fetch API，都有哪些相同与不同之处？
- fetch是用于发送请求的API
ajax是使用XMLHttpRequest发送请求
功能上基本无区别，本质区别就是用法不同 - 网上都在说fetch会慢慢取代ajax,两者的机制不同，但是实现的功能却很类似，在我浅显的理解看来：fetch采用了Promise的异步处理机制，使用比ajax更加简单，因此我觉得取代的说法是有依据的．
尝试说明 JavaScript 事件捕获和事件冒泡的区别。
- 这个题我查了不少的资料，试图能理解它，但是真的很刁钻，对于还没接触到ＪＳ的我，对于前端还没了解太多．以下内容大概是我的胡话：
- 首先我在知乎上看到这是两个完全相反的机制，一个从上到下，一个从下到上．avaScript中事件流描述的是从页面中接收事件的顺序，但是有意思的是，IE和Netscape开发团队居然提出了差不多是完全相反的事件流的概念。IE的事件流是事件冒泡，而Netscape Communicator的事件流是事件捕获流。
- 再说说这两种情况发生的情况：首先打个比方：如果桌子上有很多同心圆，我用手指到最里面的圆，从大体上讲我指的不只是一个圆，而是包括它以及套住它的所有圆．那么我们在点击网页时，点击一个按钮，其实另一种意义上，我是点击了整个页面．如果我点击了页面，从代码上看，这个行为会从＜div>依次传播到＜body>,<html>,document．这个过程是从下（子代吧？？）一下一下传达到上（父代吧？？）的．就像水里冒泡一样.
- 事件捕获：和事件冒泡相反，不太具体地节点应该更早接收到事件，而最具体的节点应该最后接收到事件。事件捕获的用意在于在时间到达预定目标之前捕获它。如果仍以前面的html页面作为演示事件捕获的例子，那么单击<div>元素就会以下列顺序触发。document,<html>,<body>,<div>.
- 那到底用哪个？大部分浏览器都是从window对象开始捕获事件的。 因此我们通常用事件冒泡，很少有人使用事件捕获模型。
- 那为啥都说要阻止事件冒泡？以我的理解来看，如果有一个表格，要输入很多个信息，如果我们在每个输入框加一个检查输入内容的东西，那会很麻烦，那我们在表头，在ｔａｂｌｅ那里加个检查的东西，只要输入，那他就能监视到（爸爸看儿子的意思），那我们在事件冒泡的时候，某个DOM（这个我还不懂）节点绑定了某事件监听器，本来是想当该DOM节点触发事件，才会执行回调函数。结果是该节点的某后代节点（就是儿子的行为影响了他爸爸的工作）触发某事件，由于事件冒泡，该DOM节点事件也会触发，执行了回调函数，这样就会在事件冒泡的时候出现错误的信息。
网友评论