1.以下代码将输出什么?
list = [‘a’, ‘b’, ‘c’, ‘d’, ‘e’]
print list[10:]
答案
以上代码将输出 []，并且不会导致一个 IndexError。
正如人们所期望的，试图访问一个超过列表索引值的成员将导致 IndexError（比如访问以上列表的 list[10]）。尽管如此，试图访问一个列表的以超出列表成员数作为开始索引的切片将不会导致 IndexError，并且将仅仅返回一个空列表。
一个讨厌的小问题是它会导致出现 bug ，并且这个问题是难以追踪的，因为它在运行时不会引发错误。
2.以下的代码的输出将是什么? 说出你的答案并解释？
def multipliers():
return [lambda x : i * x for i in range(4)]
print([m(2) for m in multipliers()])你将如何修改 multipliers 的定义来产生期望的结果
答案
以上代码的输出是 [6, 6, 6, 6] （而不是 [0, 2, 4, 6]）。
这个的原因是 Python 的闭包的后期绑定导致的 late binding，这意味着在闭包中的变量是在内部函数被调用的时候被查找。所以结果是，当任何 multipliers() 返回的函数被调用，在那时，i 的值是在它被调用时的周围作用域中查找，到那时，无论哪个返回的函数被调用，for 循环都已经完成了，i 最后的值是 3，因此，每个返回的函数 multiplies 的值都是 3。因此一个等于 2 的值被传递进以上代码，它们将返回一个值 6 （比如： 3 x 2）。
（顺便说下，正如在 The Hitchhiker’s Guide to Python 中指出的，这里有一点普遍的误解，是关于 lambda 表达式的一些东西。一个 lambda 表达式创建的函数不是特殊的，和使用一个普通的 def 创建的函数展示的表现是一样的。）
这里有两种方法解决这个问题。
最普遍的解决方案是创建一个闭包，通过使用默认参数立即绑定它的参数。例如：
def multipliers():
return [lambda x, i=i : i * x for i in range(4)]另外一个选择是，你可以使用 functools.partial 函数：
from functools import partial
from operator import mul
def multipliers():
return [partial(mul, i) for i in range(4)]
3.以下的代码的输出将是什么? 说出你的答案并解释？
def extendList(val, list=[]):
list.append(val)
return list
list1 = extendList(10)
list2 = extendList(123,[])
list3 = extendList('a')
print("list1 = %s" % list1)
print("list2 = %s" % list2)
print("list3 = %s" % list3)
以上代码的输出为：
list1 = [10, ‘a’]
list2 = [123]
list3 = [10, ‘a’]
许多人会错误的认为 list1 应该等于 [10] 以及 list3 应该等于 [‘a’]。认为 list 的参数会在 extendList 每次被调用的时候会被设置成它的默认值 []。
尽管如此，实际发生的事情是，新的默认列表仅仅只在函数被定义时创建一次。随后当 extendList 没有被指定的列表参数调用的时候，其使用的是同一个列表。这就是为什么当函数被定义的时候，表达式是用默认参数被计算，而不是它被调用的时候。
因此，list1 和 list3 是操作的相同的列表。而 `list2是操作的它创建的独立的列表（通过传递它自己的空列表作为list 参数的值）。
extendList 函数的定义可以做如下修改，但，当没有新的 list 参数被指定的时候，会总是开始一个新列表，这更加可能是一直期望的行为。
def extendList(val, list=None):
if list is None:
list = []
list.append(val)
return list使用这个改进的实现，输出将是：
list1 = [10]
list2 = [123]
list3 = [‘a’]
4.Python自省
自省就是面向对象的语言所写的程序在运行时，就能知道对象的类型。也就是程序运行时能够获得对象的类型。比如type()，dir()，getattr()，hasattr()，isinstance()。
a = [1, 2, 3]
b = {'a':1, 'b':2, 'c':3}
c = True
print(type(a), type(b), type(c))
print(isinstance(a, list))
# <class 'list'> <class 'dict'> <class 'bool'>
# True
5.三次握手，四次挥手
1 三次握手
客户端通过向服务器端发送一个SYN来创建一个主动打开，作为三次握手的一部分。客户端把这段连接的序号设定为随机数 A。
服务器端应当为一个合法的SYN回送一个SYN/ACK。ACK 的确认码应为 A+1，SYN/ACK 包本身又有一个随机序号 B。
最后，客户端再发送一个ACK。当服务端受到这个ACK的时候，就完成了三路握手，并进入了连接创建状态。此时包序号被设定为收到的确认号 A+1，而响应则为 B+1。
2 四次挥手
注意: 中断连接端可以是客户端，也可以是服务器端. 下面仅以客户端断开连接举例, 反之亦然.
客户端发送一个数据分段, 其中的 FIN 标记设置为1. 客户端进入 FIN-WAIT 状态. 该状态下客户端只接收数据, 不再发送数据.
服务器接收到带有 FIN = 1 的数据分段, 发送带有 ACK = 1 的剩余数据分段, 确认收到客户端发来的 FIN 信息.
服务器等到所有数据传输结束, 向客户端发送一个带有 FIN = 1 的数据分段, 并进入 CLOSE-WAIT 状态, 等待客户端发来带有 ACK = 1 的确认报文.
客户端收到服务器发来带有 FIN = 1 的报文, 返回 ACK = 1 的报文确认, 为了防止服务器端未收到需要重发, 进入 TIME-WAIT 状态. 服务器接收到报文后关闭连接. 客户端等待 2MSL 后未收到回复, 则认为服务器成功关闭, 客户端关闭连接.
6.apache和nginx的区别
nginx 相对 apache 的优点：
轻量级，同样起web 服务，比apache 占用更少的内存及资源
抗并发，nginx 处理请求是异步非阻塞的，支持更多的并发连接，而apache 则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能
配置简洁
高度模块化的设计，编写模块相对简单
社区活跃
apache 相对nginx 的优点：
rewrite ，比nginx 的rewrite 强大
模块超多，基本想到的都可以找到
少bug ，nginx 的bug 相对较多
超稳定
7.SOAP
SOAP（原为Simple Object Access Protocol的首字母缩写，即简单对象访问协议）是交换数据的一种协议规范，使用在计算机网络Web服务（web service）中，交换带结构信息。SOAP为了简化网页服务器（Web Server）从XML数据库中提取数据时，节省去格式化页面时间，以及不同应用程序之间按照HTTP通信协议，遵从XML格式执行资料互换，使其抽象于语言实现、平台和硬件。
8.RPC
RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
总结:服务提供的两大流派.传统意义以方法调用为导向通称RPC。为了企业SOA,若干厂商联合推出webservice,制定了wsdl接口定义,传输soap.当互联网时代,臃肿SOA被简化为http+xml/json.但是简化出现各种混乱。以资源为导向,任何操作无非是对资源的增删改查，于是统一的REST出现了.
进化的顺序: RPC -> SOAP -> RESTful
9.CGI和WSGI
CGI是通用网关接口，是连接web服务器和应用程序的接口，用户通过CGI来获取动态数据或文件等。 CGI程序是一个独立的程序，它可以用几乎所有语言来写，包括perl，c，lua，python等等。
WSGI, Web Server Gateway Interface，是Python应用程序或框架和Web服务器之间的一种接口，WSGI的其中一个目的就是让用户可以用统一的语言(Python)编写前后端。
官方说明：PEP-3333
10.中间人攻击
在GFW里屡见不鲜的,呵呵.
中间人攻击（Man-in-the-middle attack，通常缩写为MITM）是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。
11.c10k问题
所谓c10k问题，指的是服务器同时支持成千上万个客户端的问题，也就是concurrent 10 000 connection（这也是c10k这个名字的由来）。
C10K问题的本质上是操作系统的问题。对于Web 1.0/2.0时代的操作系统，传统的同步阻塞I/O模型处理方式都是requests per second。当创建的进程或线程多了，数据拷贝频繁（缓存I/O、内核将数据拷贝到用户进程空间、阻塞，进程/线程上下文切换消耗大， 导致操作系统崩溃，这就是C10K问题的本质。
可见, 解决C10K问题的关键就是尽可能减少这些CPU资源消耗。解决方法可以使用I/O多路复用。