百度2014校园招聘笔试题

From : http://blog.sina.com.cn/s/blog_6f83fdb40101fchk.html

一、简答题
1、OSI的七层模型。(10分)
OSI的七层模型如下图所示：

百度2014校园招聘笔试题(10月13北京)




 
2、请列举下不同进程之间共享数据的方式(至少举出三种)。(10分) 
    1、文件映射(Memory-Mapped Files)能使进程把文件内容当作进程地址间一块内存那样来对待
    2、共享内存(Shared Memory)实际就是文件映射的一种特殊情况
    3、命名管道(Named Pipe)是服务器进程和一个或多个客户进程之间通信的单向或双向管道
    4、邮件槽(Mailslots)提供进程间单向通信能力，任何进程都能建立邮件槽成为邮件槽服务器
    5、剪贴板(Clipped Board)为不同应用程序之间共享不同格式数据提供了一条捷径
    6、动态连接库(DLL)中的全局数据可以被调用DLL的所有进程共享
 
 
3、请描述下TCP和UDP的差别，并且各列举出一个上层协议。(10分) 
    TCP---传输控制协议,提供的是面向连接、可靠的字节流服务。当客户和服务器彼此交换数据前，必须先在双方之间建立一个TCP连接，之后才能传输数据。TCP提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。
 
    UDP---用户数据报协议，是一个简单的面向数据报的运输层协议。UDP不提供可靠性，它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，故而传输速度很快。
 
    经常使用“ping”命令的原理就是向对方主机发送UDP数据包，ftp等就是使用到的TCP协议  错误！！！！！！！！！！！！！！！！！

    ping使用的是ICMP协议，它和IP协议处在同一层；使用UDP协议的有DNS，使用TCP有FTP协议，SMTP/POP3协议，TELNET协议

 
二、算法与程序设计
1、给出一个数据A={a_0,a_1,a_2…a_n}(其中n可变)，打印出该数值元素的所有组合。(15分)
    因为题目要求n可变，所以不可能是n层for循环的方式，可以采用递归的方式来实现，每次取一个元素，在剩下元素的数组中递归，要注意递归结束的条件。 
 
 
2、有这样一个数组A，大小为n，相邻元素差的绝对值都是1，如A={4,5,6,5,6,7,8,9,10,9}，现在给定数组A和目标整数t，请找到t在A中的位置。(15分)
最简单的方式是循环遍历每一个元素之后比较，找到t在A中的位置，此种方法效率最低；
    改进：因为相邻元素差的绝对值都是1，那么任意两个元素相距的位置至少是两元素差的绝对值个，假设要找的元素是t，t和a(0)的差为y1=abs(t-a[0]),那么t和a[0]的距离至少是y1，再求一次差值y2=abs(t-a[y1]),t和a[y1+y2]的距离至少是y2，继续向后查找，直到相等为止，此种方法效率较前一种高
 
 
3、有一颗二叉树，定义树的高度为从根到叶子节点的最长距离，树的宽度为每层节点的最大值，树的面积定义为高度和宽度的乘积。写一个函数计算一个二叉树的面积。(15分)
    广度遍历求树的宽度，深度遍历求树的高度，之后计算面积 
 
 
三、系统设计题(25分)
 百度2014校园招聘笔试题(10月13北京)

----------------------------------------------------------------------------------------------------------------------------------------------------------------------

一.简答题

1.简述计算机的存储系统分为哪几个层次，为什么这样的分层能够提高程序的执行效率。

2.浮点数在计算中如何表示，如何对浮点数判等。

3.简述TCP与UDP协议的差别，两者与HTTP的关系。并列举HTTP的方法，以及常见的返回状态码。

文章链接： http://www.iteye.com/topic/1124408

引用

学习Web开发不好好学习HTTP报文，将会“打拳不练功，到老一场空”，你花在犯迷糊上的时间比你沉下心来学习HTTP的时间肯定会多很多。

HTTP请求报文解剖  

HTTP请求报文由3部分组成（ 请求行+请求头+请求体 ）： 

 

下面是一个实际的请求报文： 

 

①是请求方法，GET和POST是最常见的HTTP方法，除此以外还包括DELETE、HEAD、OPTIONS、PUT、TRACE。不过，当前的大多数浏览器只支持GET和POST，Spring 3.0提供了一个HiddenHttpMethodFilter，允许你通过“_method”的表单参数指定这些特殊的HTTP方法（实际上还是通过POST提交表单）。服务端配置了HiddenHttpMethodFilter后，Spring会根据_method参数指定的值模拟出相应的HTTP方法，这样，就可以使用这些HTTP方法对处理方法进行映射了。 

②为请求对应的URL地址，它和报文头的Host属性组成完整的请求URL，③是协议名称及版本号。 

④是HTTP的报文头，报文头包含若干个属性，格式为“属性名:属性值”，服务端据此获取客户端的信息。 

⑤是报文体，它将一个页面表单中的组件值通过param1=value1&param2=value2的键值对形式编码成一个格式化串，它承载多个请求参数的数据。不但报文体可以传递请求参数，请求URL也可以通过类似于“/chapter15/user.html? param1=value1&param2=value2”的方式传递请求参数。 

对照上面的请求报文，我们把它进一步分解，你可以看到一幅更详细的结构图： 

 

引用

HttpWatch是强大的网页数据分析工具，安装后将集成到Internet Explorer工具栏中。它不用代理服务器或一些复杂的网络监控工具，就能抓取请求及响应的完整信息，包括Cookies、消息头、查询参数、响应报文等，是Web应用开发人员的必备工具。

HTTP请求报文头属性  

报文头属性是什么东西呢？我们不妨以一个小故事来说明吧。 

引用

快到中午了，张三丰不想去食堂吃饭，于是打电话叫外卖：老板，我要一份[鱼香肉丝]，要12：30之前给我送过来哦，我在江湖湖公司研发部，叫张三丰。

这里，你要[鱼香肉丝]相当于HTTP报文体，而“12：30之前送过来”，你叫“张三丰”等信息就相当于HTTP的报文头。它们是一些附属信息，帮忙你和饭店老板顺利完成这次交易。 

请求HTTP报文和响应HTTP报文都拥有若干个报文关属性，它们是为协助客户端及服务端交易的一些附属信息。 


常见的HTTP请求报文头属性  

Accept  

请求报文可通过一个“Accept”报文头属性告诉服务端 客户端接受什么类型的响应。 

如下报文头相当于告诉服务端，俺客户端能够接受的响应类型仅为纯文本数据啊，你丫别发其它什么图片啊，视频啊过来，那样我会歇菜的~~~： 

Java代码  

1. Accept:text/plain  

Accept属性的值可以为一个或多个MIME类型的值，关于MIME类型，大家请参考： http://en.wikipedia.org/wiki/MIME_type  

Cookie  

客户端的Cookie就是通过这个报文头属性传给服务端的哦！如下所示： 

Java代码  

1. Cookie: $Version=1; Skin=new;jsessionid=5F4771183629C9834F8382E23BE13C4C  

服务端是怎么知道客户端的多个请求是隶属于一个Session呢？注意到后台的那个jsessionid=5F4771183629C9834F8382E23BE13C4C木有？原来就是通过HTTP请求报文头的Cookie属性的jsessionid的值关联起来的！（当然也可以通过重写URL的方式将会话ID附带在每个URL的后面哦）。 


Referer  

表示这个请求是从哪个URL过来的，假如你通过google搜索出一个商家的广告页面，你对这个广告页面感兴趣，鼠标一点发送一个请求报文到商家的网站，这个请求报文的Referer报文头属性值就是http://www.google.com。 

引用

唐僧到了西天. 
如来问：侬是不是从东土大唐来啊？ 
唐僧：厉害！你咋知道的！ 
如来：呵呵，我偷看了你的Referer... 

很多貌似神奇的网页监控软件（如著名的  我要啦 ），只要在你的网页上放上一段JavaScript，就可以帮你监控流量，全国访问客户的分布情况等报表和图表，其原理就是通过这个Referer及其它一些HTTP报文头工作的。 

Cache-Control  

对缓存进行控制，如一个请求希望响应返回的内容在客户端要被缓存一年，或不希望被缓存就可以通过这个报文头达到目的。 

如以下设置，相当于让服务端将对应请求返回的响应内容不要在客户端缓存： 

Java代码  

1. Cache-Control: no-cache  

其它请求报文头属性  

参见： http://en.wikipedia.org/wiki/List_of_HTTP_header_fields  

如何访问请求报文头  

由于请求报文头是客户端发过来的，服务端当然只能读取了，以下是HttpServletRequest一些用于读取请求报文头的API： 

Java代码  

1. //获取请求报文中的属性名称  
2. java.util.Enumeration<java.lang.String>   getHeaderNames();  
3.   
4. //获取指定名称的报文头属性的值  
5. java.lang.String getHeader(java.lang.String name)   

由于一些请求报文头属性“太著名”了，因此HttpServletRequest为它们提供了VIP的API： 

Java代码  

1. //获取报文头中的Cookie(读取Cookie的报文头属性）  
2.  Cookie[]   getCookies() ;  
3.   
4. //获取客户端本地化信息（读取 Accept-Language 的报文头属性）  
5. java.util.Locale    getLocale()   
6.   
7. //获取请求报文体的长度（读取Content-Length的报文头属性）  
8. int getContentLength();  

HttpServletRequest可以通过 

Java代码  

1. HttpSession getSession()   

获取请求所关联的HttpSession,其内部的机理是通过读取请求报文头中Cookie属性的JSESSIONID的值，在服务端的一个会话Map中，根据这个JSESSIONID获取对应的HttpSession的对象。（这样，你就不会觉得HttpSession很神秘了吧，你自己也可以做一个类似的会话管理   ） 

HTTP响应报文解剖  

响应报文结构  

HTTP的响应报文也由三部分组成（ 响应行+响应头+响应体 ）： 

 

以下是一个实际的HTTP响应报文： 

 

①报文协议及版本； 
②状态码及状态描述； 
③响应报文头，也是由多个属性组成； 
④响应报文体，即我们真正要的“干货”。 

响应状态码  

和请求报文相比，响应报文多了一个“响应状态码”，它以“清晰明确”的语言告诉客户端本次请求的处理结果。 

HTTP的响应状态码由5段组成： 

• 1xx 消息，一般是告诉客户端，请求已经收到了，正在处理，别急...
• 2xx 处理成功，一般表示：请求收悉、我明白你要的、请求已受理、已经处理完成等信息.
• 3xx 重定向到其它地方。它让客户端再发起一个请求以完成整个处理。
• 4xx 处理发生错误，责任在客户端，如客户端的请求一个不存在的资源，客户端未被授权，禁止访问等。
• 5xx 处理发生错误，责任在服务端，如服务端抛出异常，路由出错，HTTP版本不支持等。

以下是几个常见的状态码： 

200 OK  

你最希望看到的，即处理成功！ 

303 See Other  

我把你redirect到其它的页面，目标的URL通过响应报文头的Location告诉你。 

引用

悟空：师傅给个桃吧，走了一天了  
唐僧：我哪有桃啊！去王母娘娘那找吧

304 Not Modified  

告诉客户端，你请求的这个资源至你上次取得后，并没有更改，你直接用你本地的缓存吧，我很忙哦，你能不能少来烦我啊！ 

403

Forbidden

服务器理解请求客户端的请求，但是拒绝执行此请求

404 Not Found  

你最不希望看到的，即找不到页面。如你在google上找到一个页面，点击这个链接返回404，表示这个页面已经被网站删除了，google那边的记录只是美好的回忆。 

500 Internal Server Error  

看到这个错误，你就应该查查服务端的日志了，肯定抛出了一堆异常，别睡了，起来改BUG去吧！ 


其它的状态码参见： http://en.wikipedia.org/wiki/List_of_HTTP_status_codes  


有些响应码，Web应用服务器会自动给生成。你可以通过HttpServletResponse的API设置状态码： 

Java代码  

1. //设置状态码，状态码在HttpServletResponse中通过一系列的常量预定义了，如SC_ACCEPTED，SC_OK  
2. void    setStatus(int sc)   

常见的HTTP响应报文头属性  

Cache-Control  

响应输出到客户端后，服务端通过该报文头属告诉客户端如何控制响应内容的缓存。 

下面，的设置让客户端对响应内容缓存3600秒，也即在3600秒内，如果客户再次访问该资源，直接从客户端的缓存中返回内容给客户，不要再从服务端获取 （当然，这个功能是靠客户端实现的，服务端只是通过这个属性提示客户端“应该这么做”，做不做，还是决定于客户端，如果是自己宣称支持HTTP的客户端，则就应该这样实现） 。 

Java代码  

1. Cache-Control: max-age=3600  

ETag  

一个代表响应服务端资源（如页面）版本的报文头属性，如果某个服务端资源发生变化了，这个ETag就会相应发生变化。它是Cache-Control的有益补充，可以让客户端“更智能”地处理什么时候要从服务端取资源，什么时候可以直接从缓存中返回响应。 

关于ETag的说明，你可以参见： http://en.wikipedia.org/wiki/HTTP_ETag 。 
Spring 3.0还专门为此提供了一个org.springframework.web.filter.ShallowEtagHeaderFilter（实现原理很简单，对JSP输出的内容MD5，这样内容有变化ETag就相应变化了），用于生成响应的ETag，因为这东东确实可以帮助减少请求和响应的交互。 

下面是一个ETag： 

Java代码  

1. ETag: "737060cd8c284d8af7ad3082f209582d"  

Location  

我们在JSP中让页面Redirect到一个某个A页面中，其实是让客户端再发一个请求到A页面，这个需要Redirect到的A页面的URL，其实就是通过响应报文头的Location属性告知客户端的，如下的报文头属性，将使客户端redirect到iteye的首页中： 

Java代码  

1. Location: http://www.iteye.com  

Set-Cookie  

服务端可以设置客户端的Cookie，其原理就是通过这个响应报文头属性实现的： 

Java代码  

1. Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1  

其它HTTP响应报文头属性  

更多其它的HTTP响应头报文，参见： http://en.wikipedia.org/wiki/List_of_HTTP_header_fields  


如何写HTTP请求报文头  

在服务端可以通过HttpServletResponse的API写响应报文头的属性： 

Java代码  

1. //添加一个响应报文头属性  
2. void    setHeader(String name, String value)   

象Cookie，Location这些响应都是有福之人，HttpServletResponse为它们都提供了VIP版的API： 

Java代码  

1. //添加Cookie报文头属性  
2. void addCookie(Cookie cookie)   
3.   
4. //不但会设置Location的响应报文头，还会生成303的状态码呢，两者天仙配呢  
5. void    sendRedirect(String location)   

TCP/IP、Http、Socket的区别

• 浏览：4674
• |
• 更新：2013-06-01 14:21

 

　　网络由下往上分为

　　物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。

　　通过初步的了解，我知道IP协议对应于网络层，TCP协议对应于传输层，而HTTP协议对应于应用层，

　　三者从本质上来说没有可比性，

　　socket则是对TCP/IP协议的封装和应用(程序员层面上)。

　　也可以说，TPC/IP协议是传输层协议，主要解决数据如何在网络中传输，

　　而HTTP是应用层协议，主要解决如何包装数据。

　　关于TCP/IP和HTTP协议的关系，网络有一段比较容易理解的介绍：

　　“我们在传输数据时，可以只使用(传输层)TCP/IP协议，但是那样的话，如果没有应用层，便无法识别数据内容。

　　如果想要使传输的数据有意义，则必须使用到应用层协议。

　　应用层协议有很多，比如HTTP、FTP、TELNET等，也可以自己定义应用层协议。

　　WEB使用HTTP协议作应用层协议，以封装HTTP文本信息，然后使用TCP/IP做传输层协议将它发到网络上。”

　　而我们平时说的最多的socket是什么呢，实际上socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口(API)。

　　通过Socket，我们才能使用TCP/IP协议。

　　实际上，Socket跟TCP/IP协议没有必然的联系。

　　Socket编程接口在设计的时候，就希望也能适应其他的网络协议。

　　所以说，Socket的出现只是使得程序员更方便地使用TCP/IP协议栈而已，是对TCP/IP协议的抽象，

　　从而形成了我们知道的一些最基本的函数接口，比如create、listen、connect、accept、send、read和write等等。

　　网络有一段关于socket和TCP/IP协议关系的说法比较容易理解：

　　“TCP/IP只是一个协议栈，就像操作系统的运行机制一样，必须要具体实现，同时还要提供对外的操作接口。

　　这个就像操作系统会提供标准的编程接口，比如win32编程接口一样，

　　TCP/IP也要提供可供程序员做网络开发所用的接口，这就是Socket编程接口。”

　　关于TCP/IP协议的相关只是，用博大精深来讲我想也不为过，单单查一下网上关于此类只是的资料和书籍文献的数量就知道，

　　这个我打算会买一些经典的书籍(比如《TCP/IP详解：卷一、卷二、卷三》)进行学习，今天就先总结一些基于基于TCP/IP协议的应用和编程接口的知识，也就是刚才说了很多的HTTP和Socket。

　　优快云上有个比较形象的描述：HTTP是轿车，提供了封装或者显示数据的具体形式;Socket是发动机，提供了网络通信的能力。

　　实际上，传输层的TCP是基于网络层的IP协议的，而应用层的HTTP协议又是基于传输层的TCP协议的，而Socket本身不算是协议，就像上面所说，它只是提供了一个针对TCP或者UDP编程的接口。

　　下面是一些经常在笔试或者面试中碰到的重要的概念，特在此做摘抄和总结。

　　一、什么是TCP连接的三次握手

　　第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认;

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

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

　　握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。

　　理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。

　　断开连接时服务器和客户端均可以主动发起断开TCP连接的请求，断开过程需要经过“四次握手”(过程就不细写了，就是服务器和客户端交互，最终确定断开)

　　二、利用Socket建立网络连接的步骤

　　建立Socket连接至少需要一对套接字，其中一个运行于客户端，称为ClientSocket ，另一个运行于服务器端，称为ServerSocket 。

　　套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。

　　1、服务器监听：服务器端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态，等待客户端的连接请求。

　　2、客户端请求：指客户端的套接字提出连接请求，要连接的目标是服务器端的套接字。

　　为此，客户端的套接字必须首先描述它要连接的服务器的套接字，指出服务器端套接字的地址和端口号，然后就向服务器端套接字提出连接请求。

　　3、连接确认：当服务器端套接字监听到或者说接收到客户端套接字的连接请求时，就响应客户端套接字的请求，建立一个新的线程，把服务器端套接字的描述发给客户端，一旦客户端确认了此描述，双方就正式建立连接。

　　而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。

　　三、HTTP链接的特点

　　HTTP协议即超文本传送协议(Hypertext Transfer Protocol )，是Web联网的基础，也是手机联网常用的协议之一，HTTP协议是建立在TCP协议之上的一种应用。

　　HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。

　　四、TCP和UDP的区别(考得最多。。快被考烂了我觉得- -\\)

　　1、TCP是面向链接的，虽然说网络的不安全不稳定特性决定了多少次握手都不能保证连接的可靠性，但TCP的三次握手在最低限度上(实际上也很大程度上保证了)保证了连接的可靠性;

　　而UDP不是面向连接的，UDP传送数据前并不与对方建立连接，对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收，当然也不用重发，所以说UDP是无连接的、不可靠的一种数据传输协议。

　　2、也正由于1所说的特点，使得UDP的开销更小数据传输速率更高，因为不必进行收发数据的确认，所以UDP的实时性更好。

　　知道了TCP和UDP的区别，就不难理解为何采用TCP传输协议的MSN比采用UDP的QQ传输文件慢了，但并不能说QQ的通信是不安全的，

　　因为程序员可以手动对UDP的数据收发进行验证，比如发送方对每个数据包进行编号然后由接收方进行验证啊什么的，

　　即使是这样，UDP因为在底层协议的封装上没有采用类似TCP的“三次握手”而实现了TCP所无法达到的传输效率。

二.算法与程序设计

1.设计一个反转字符串的函数 char *reverse_str(char *str),不使用系统函数。

2.给定一个字符串,（1，（2，3），（4，（5，6），7））,使它变为（1，2，3，4，5，6，7），设计一个算法消除其中嵌套的括号。(c/c++)

3.使用C语言实现htonl（将long性转为网络字节码），不使用系统自带函数。

例如 int a = 0x12345678，b = htonl（a），那么就应该是0x78563412

a) Little-Endian就是低位字节排放在内存的低地址端，高位字节排放在内存的高地址端。 
b) Big-Endian就是高位字节排放在内存的低地址端，低位字节排放在内存的高地址端。 
c) 网络字节序：TCP/IP各层协议将字节序定义为Big-Endian，因此TCP/IP协议中使用的字节序通常称之为网络字节序。 

以上图为例如果我们在栈上分配一个unsigned char buf[4]，那么这个数组变量在栈上是如何布局的呢？看下图： 
栈底（高地址） 
---------- 
buf[3] 
buf[2] 
buf[1] 
buf[0] 
---------- 
栈顶（低地址） 

现在我们弄清了高低地址，接着我来弄清高/低字节，如果我们有一个32位无符号整型0x12345678(呵呵，恰好是把上面的那4个字节buf看成一个整型)，那么高位是什么，低位又是什么呢？其实很简单。在十进制中我们都说靠左边的是高位，靠右边的是低位，在其他进制也是如此。就拿0x12345678来说，从高位到低位的字节依次是0x12、0x34、0x56和0x78。 
高低地址和高低字节都弄清了。我们再来回顾一下Big-Endian和Little-Endian的定义，并用图示说明两种字节序： 
以unsigned int value = 0x12345678为例，分别看看在两种字节序下其存储情况，我们可以用unsigned char buf[4]来表示value： 
Big-Endian: 低地址存放高位，如下图： 
栈底（高地址） 
--------------- 
buf[3] (0x78) -- 低位 
buf[2] (0x56) 
buf[1] (0x34) 
buf[0] (0x12) -- 高位 
--------------- 
栈顶（低地址） 
Little-Endian: 低地址存放低位，如下图： 
栈底（高地址） 
--------------- 
buf[3] (0x12) -- 高位 
buf[2] (0x34) 
buf[1] (0x56) 
buf[0] (0x78) -- 低位 
--------------- 
栈顶（低地址） 

在现有的平台上Intel的X86采用的是Little-Endian，而像Sun的SPARC采用的就是Big-Endian。 

三.系统设计题

面向对象是一种思想，使用C语言来实现下列问题。

1.如何定义一个类？

2.如何创建以及销毁对象？

3.如何实现类的继承？

从上面来看，

计算机原理知识两道，网络协议方面一道，其余都为C方面的考察，两道字符串处理，一个C和面向对象思想的结合。

也希望所有要毕业的童鞋们加油:-)