Python网络编程基础第三版

需积分: 9 121 浏览量更新于2024-07-22 收藏 3.34MB PDF 举报

"《Python网络编程基础第3版》" 本书是关于Python网络编程的一本经典著作，适合初学者和有经验的开发者。它详细介绍了使用Python进行网络通信的各种技术，包括客户端-服务器架构、传输协议（如UDP和TCP）、套接字编程、域名解析、错误处理、安全通信（TLS/SSL）、服务器设计、缓存与消息队列、HTTP协议以及电子邮件处理等。在"Introduction"中，作者提到Python社区经过二十多年的创新，语言已经发展成熟，成为网络编程的理想选择。书中将引导读者通过实例学习如何利用Python构建功能强大的网络应用程序。 Chapter 1 "Introduction to Client-Server Networking" 概述了客户端-服务器模型的基础知识，包括它们的工作原理和在实际应用中的重要性。读者将了解到如何使用Python建立基本的客户端和服务器程序。 Chapter 2 "UDP"介绍了无连接的用户数据报协议（UDP），讲解了其特点和使用场景，以及如何在Python中实现UDP通信。 Chapter 3 "TCP"深入讨论了面向连接的传输控制协议（TCP），包括连接建立、数据传输和断开连接的流程，以及Python中的socket接口。 Chapter 4 "Socket Names and DNS"涉及套接字命名和域名系统（DNS）查询，讲解了如何解析和构建IP地址，以及如何用Python进行DNS查找。 Chapter 5 "Network Data and Network Errors"探讨了网络数据的编码和解码，以及如何处理网络错误，确保程序的健壮性。 Chapter 6 "TLS/SSL"介绍了用于加密通信的传输层安全（TLS）和安全套接字层（SSL），讲解了如何在Python中实现安全的网络连接。 Chapter 7 "Server Architecture"涵盖了服务器设计的多个方面，包括多线程、异步I/O和并发处理策略。 Chapter 8 "Caches and Message Queues"讨论了缓存机制和消息队列，如何利用这些技术提高网络应用的性能和可扩展性。 Chapter 9 "HTTP Clients"和Chapter 10 "HTTP Servers"分别讲述了如何使用Python创建HTTP客户端和服务器，涵盖了HTTP协议的基本概念和实现。 Chapter 11 "The World Wide Web"深入到万维网的细节，包括网页抓取和解析，以及Web服务的交互。 Chapter 12 "Building and Parsing E-Mail"涵盖了电子邮件的构建和解析，包括MIME标准和邮件头的处理。 Chapter 13 "SMTP"、Chapter 14 "POP"和Chapter 15 "IMAP"分别讲解了简单邮件传输协议（SMTP）、邮局协议（POP）和因特网消息访问协议（IMAP），这些都是处理电子邮件的关键协议。 Chapter 16 "Telnet and SSH"涵盖了远程终端访问协议（Telnet）和安全外壳协议（SSH），讨论了如何使用Python实现远程登录和安全的命令行交互。 Chapter 17 "FTP"介绍了文件传输协议（FTP），讲解了如何使用Python实现FTP客户端和服务器。 Chapter 18 "RPC"探讨了远程过程调用（RPC），它是分布式系统中的一种通信机制。书末的索引方便读者快速定位所需的信息。通过阅读本书，读者不仅可以掌握Python网络编程的基础，还能获得构建复杂网络应用的实战经验，从而在Python网络编程领域打下坚实的基础。

Chapter 1 ■ IntroduCtIon to ClIent-Server networkIng

The reply, which will print as the script’s output if you run search4.py, is shown as Listing 1-5. I chose simply to

print the reply to the screen in this example, rather than write the complex text-manipulation code that would be able

to interpret the response. I did so because I thought that simply reading the HTTP reply on your screen would give you

a much better idea of what it looks like than if you had to decipher code designed to interpret it.

Listing 1-5. The Output of Running search4.py

HTTP/1.1 200 OK

Content-Type: application/json; charset=UTF-8

Date: Sat, 23 Nov 2013 18:34:30 GMT

Expires: Sun, 24 Nov 2013 18:34:30 GMT

Cache-Control: public, max-age=86400

Vary: Accept-Language

Access-Control-Allow-Origin: *

Server: mafe

X-XSS-Protection: 1; mode=block

X-Frame-Options: SAMEORIGIN

Alternate-Protocol: 80:quic

Connection: close

{

"results" : [

{

...

"formatted_address" : "207 North Defiance Street, Archbold, OH 43502, USA",

"geometry" : {

"location" : {

"lat" : 41.521954,

"lng" : -84.306691

...

"types" : [ "street_address" ]

}

"status" : "OK"

}

You can see that the HTTP reply is quite similar in structure to the HTTP request. It begins with a status line,

which is followed by a number of headers. After a blank line, the response content itself is shown: a JavaScript data

structure, in a simple format known as JSON, that answers your query by describing the geographic location that the

Google Geocoding API search has returned.

All of these status lines and headers, of course, are exactly the sort of low-level details that Python’s httplib

was taking care of in the earlier listings. Here, you see what the communication looks like if that layer of software is

stripped away.

Chapter 1 ■ IntroduCtIon to ClIent-Server networkIng

Turtles All the Way Down

I hope you have enjoyed these initial examples of what Python network programming can look like. Stepping back,

I can use this series of examples to make several points about network programming in Python.

First, you can perhaps now see more clearly what is meant by the term protocol stack: it means building a

high-level, semantically sophisticated conversation (“I want the geographic location of this mailing address”) on top

of simpler, and more rudimentary, conversations that ultimately are just text strings sent back and forth between two

computers using their network hardware.

The particular protocol stack that you have just explored is four protocols high.

On top is the Google Geocoding API, which tells you how to express your geographic queries •

as URLs that fetch JSON data containing coordinates.

URLs name documents that can be retrieved using HTTP.•

HTTP supports document-oriented commands such as GET using raw TCP/IP sockets.•

TCP/IP sockets know how only to send and receive byte strings.•

Each layer of the stack, you see, uses the tools provided by the layer beneath it and in turn offers capabilities to

the next higher layer.

A second point made clear through these examples is how very complete the Python support is for every one

of the network levels at which you have just operated. Only when using a vendor-specific protocol, and needing to

format requests so that Google would understand them, was it necessary to resort to using a third-party library; I chose

requests for the second listing not because the Standard Library lacks the urllib.request module but because its API

is overly clunky. Every single one of the other protocol levels you encountered already had strong support inside the

Python Standard Library. Whether you wanted to fetch the document at a particular URL or send and receive strings on

a raw network socket, Python was ready with functions and classes that you could use to get the job done.

Third, note that my programs decreased considerably in quality as I forced myself to use increasingly lower-level

protocols. The search2.py and search3.py listings, for example, started to hard-code things such as the form

structure and hostnames in a way that is inflexible and that might be hard to maintain later. The code in search4.py

is even worse: it includes a handwritten, unparameterized HTTP request whose structure is completely opaque to

Python. And, of course, it contains none of the actual logic that would be necessary to parse and interpret the HTTP

response and understand any network error conditions that might occur.

This illustrates a lesson that you should remember throughout every subsequent chapter of this book: that

implementing network protocols correctly is difficult and that you should use the Standard Library or third-party

libraries whenever possible. Especially when you are writing a network client, you will always be tempted to

oversimplify your code; you will tend to ignore many error conditions that might arise, to prepare for only the most

likely responses, to avoid properly escaping parameters because you fondly believe that your query strings will only

ever include simple alphabetic characters, and, in general, to write very brittle code that knows as little about the

service it is talking to as is technically possible. By instead using a third-party library that has developed a thorough

implementation of a protocol, which has had to support many different Python developers who are using the library

for a variety of tasks, you will benefit from all of the edge cases and awkward corners that the library implementer has

already discovered and learned how to handle properly.

Fourth, it needs to be emphasized that higher-level network protocols—such as the Google Geocoding API

for resolving a street address—generally work by hiding the network layers beneath them. If you only ever used the

pygeocoder library, you might not even be aware that URLs and HTTP are the lower-level mechanisms that are being

used to construct and answer your queries!

An interesting question, whose answer varies depending on how carefully a Python library has been written, is

whether the library correctly hides errors at those lower levels. Could a network error that makes Google temporarily

unreachable from your location raise a raw, low-level networking exception in the middle of code that’s just trying

to find the coordinates of a street address? Or will all errors be changed into a higher-level exception specific to

geocoding? Pay careful attention to the topic of catching network errors as you go forward throughout this book,

especially in the chapters of this first part with their emphasis on low-level networking.

Chapter 1 ■ IntroduCtIon to ClIent-Server networkIng

Finally, we have reached the topic that will occupy you for the rest of this first part of the book: the socket()

interface used in search4.py is not, in fact, the lowest protocol level in play when you make this request to Google!

Just as the example has network protocols operating above the level above raw sockets, so also there are protocols

down beneath the sockets abstraction that Python cannot see because your operating system manages them instead.

The layers operating below the socket() API are the following:

The Transmission Control Protocol (TCP) supports two-way conversations made of streams of •

bytes by sending (or perhaps re-sending), receiving, and re-ordering small network messages

called packets.

The Internet Protocol (IP) knows how to send packets between different computers.•

The “link layer,” at the very bottom, consists of network hardware devices such as Ethernet •

ports and wireless cards, which can send physical messages between directly linked

computers.

Throughout the rest of this chapter, and in the two chapters that follow, you will explore these lowest protocol

levels. You will start in this chapter by examining the IP level and then proceed in the following chapters to see how

two quite different protocols—UDP and TCP—support the two basic kinds of conversation that are possible between

applications on a pair of Internet-connected hosts.

But first, a few words about bytes and characters.

Encoding and Decoding

The Python 3 language makes a strong distinction between strings of characters and low-level sequences of bytes.

Bytes are the actual binary numbers that computers transmit back and forth during network communication, each

consisting of eight binary digits and ranging from the binary value 00000000 to 11111111 and thus from the decimal

integer 0 to 255. Strings of characters in Python can contain Unicode symbols like a (“Latin small letter A,” the Unicode

standard calls it) or } (“right curly bracket”) or ∅ (empty set). While each Unicode character does indeed each have

a numeric identifier associated with it, called its code point, you can treat this as an internal implementation detail—

Python 3 is careful to make characters always behave like characters, and only when you ask will Python convert the

characters to and from actual externally visible bytes.

These two operations have formal names.

Decoding is what happens when bytes are on their way into your application and you need to figure out what they

mean. Think of your application, as it receives bytes from a file or across the network, as a classic Cold War spy whose

task is to decipher the transmission of raw bytes arriving from across a communications channel.

Encoding is the process of taking character strings that you are ready to present to the outside world and turning

them into bytes using one of the many encodings that digital computers use when they need to transmit or store

symbols using the bytes that are their only real currency. Think of your spy as having to turn their message back into

numbers for transmission, as turning the symbols into a code that can be sent across the network.

These two operations are exposed quite simply and obviously in Python 3 as a decode() method that you can

apply to byte strings after reading them in and as an encode() method that you can call on character strings when you

are ready to write them back out. The techniques are illustrated in Listing 1-6.

Listing 1-6. Decoding Input Bytes and Encoding Characters for Output

#!/usr/bin/env python3

# Foundations of Python Network Programming, Third Edition

# https://github.com/brandon-rhodes/fopnp/blob/m/py3/chapter01/stringcodes.py

if __name__ == '__main__':

# Translating from the outside world of bytes to Unicode characters.

input_bytes = b'\xff\xfe4\x001\x003\x00 \x00i\x00s\x00 \x00i\x00n\x00.\x00'

Chapter 1 ■ IntroduCtIon to ClIent-Server networkIng

input_characters = input_bytes.decode('utf-16')

print(repr(input_characters))

# Translating characters back into bytes before sending them.

output_characters = 'We copy you down, Eagle.\n'

output_bytes = output_characters.encode('utf-8')

with open('eagle.txt', 'wb') as f:

f.write(output_bytes)

The examples in this book attempt to differentiate carefully between bytes and characters. Note that the two have

different appearances when you display their repr(): byte strings start with the letter b and look like b'Hello', while

real full-fledged character strings take no initial character and simply look like 'world'. To try to discourage confusion

between byte strings and character strings, Python 3 offers most string methods only on the character string type.

The Internet Protocol

Both networking, which occurs when you connect several computers with a physical link so that they can

communicate, and internetworking, which links adjacent physical networks to form a much larger system like the

Internet, are essentially just elaborate schemes to allow resource sharing.

All sorts of things in a computer, of course, need to be shared: disk drives, memory, and the CPU are all carefully

guarded by the operating system so that the individual programs running on your computer can access those

resources without stepping on each other’s toes. The network is yet another resource that the operating system needs

to protect so that programs can communicate with one another without interfering with other conversations that

happen to be occurring on the same network.

The physical networking devices that your computer uses to communicate—like Ethernet cards, wireless

transmitters, and USB ports—are themselves each designed with an elaborate ability to share a single physical

medium among many different devices that want to communicate. A dozen Ethernet cards might be plugged into the

same hub; 30 wireless cards might be sharing the same radio channel; and a DSL modem uses frequency-domain

multiplexing, a fundamental concept in electrical engineering, to keep its own digital signals from interfering with the

analog signals sent down the line when you talk on the telephone.

The fundamental unit of sharing among network devices—the currency, if you will, in which they trade—is

the packet. A packet is a byte string whose length might range from a few bytes to a few thousand bytes, which is

transmitted as a single unit between network devices. Although specialized networks do exist, especially in realms

such as telecommunications, where each individual byte coming down a transmission line might be separately

routed to a different destination, the more general-purpose technologies used to build digital networks for modern

computers are all based on the larger unit of the packet.

A packet often has only two properties at the physical level: the byte-string data it carries and an address to which

it is to be delivered. The address of a physical packet is usually a unique identifier that names one of the other network

cards attached to the same Ethernet segment or wireless channel as the computer transmitting the packet. The job of

a network card is to send and receive such packets without making the computer’s operating system care about the

details of how the network uses wires, voltages, and signals to operate.

What, then, is the Internet Protocol?

The Internet Protocol is a scheme for imposing a uniform system of addresses on all of the Internet-connected

computers in the entire world and to make it possible for packets to travel from one end of the Internet to the other.

Ideally, an application like your web browser should be able to connect to a host anywhere without ever knowing

which maze of network devices each packet is traversing on its journey.

It is rare for a Python program to operate at such a low level that it sees the Internet Protocol itself in action, but it

is helpful, at least, to know how it works.

Chapter 1 ■ IntroduCtIon to ClIent-Server networkIng

IP Addresses

The original version of the Internet Protocol assigns a 4-byte address to every computer connected to the worldwide

network. Such addresses are usually written as four decimal numbers, separated by periods, which each represent a

single byte of the address. Each number can therefore range from 0 to 255. So, a traditional four-byte IP address looks

like this:

130.207.244.244

Because purely numeric addresses can be difficult for humans to remember, the people using the Internet are

generally shown hostnames rather than IP addresses. The user can simply type google.com and forget that behind

the scene this resolves to an address like 74.125.67.103, to which their computer can actually address packets for

transmission over the Internet.

In the getname.py script, shown in Listing 1-7, you can see a simple Python program that asks the operating

system—Linux, Mac OS, Windows, or on whatever system the program is running—to resolve the hostname

www.python.org. The particular network service, called the Domain Name System, which springs into action to

answer hostname queries is fairly complex, and I will discuss it in greater detail in Chapter 4.

Listing 1-7. Turning a Hostname into an IP Address

#!/usr/bin/env python3

# Foundations of Python Network Programming, Third Edition

# https://github.com/brandon-rhodes/fopnp/blob/m/py3/chapter01/getname.py

import socket

if __name__ == '__main__':

hostname = 'www.python.org'

addr = socket.gethostbyname(hostname)

print('The IP address of {} is {}'.format(hostname, addr))

For now, you just need to remember two things.

First, however fancy an Internet application might look, the actual Internet Protocol always •

uses numeric IP addresses to direct packets toward their destination.

Second, the complicated details of how hostnames are resolved to IP addresses are usually •

handled by the operating system.

Like most details of the operation of the Internet Protocol, your operating system prefers to take care of them

itself, hiding the details both from you and from your Python code.

Actually, the addressing situation can be a bit more complex these days than the simple 4-byte scheme just

described. Because the world is beginning to run out of 4-byte IP addresses, an extended address scheme, called IPv6,

is being deployed that allows absolutely gargantuan 16-byte addresses that should serve humanity’s needs for a long

time to come. They are written differently from 4-byte IP addresses and look like this:

fe80::fcfd:4aff:fecf:ea4e

But as long as your code accepts IP addresses or hostnames from the user and passes them directly to a

networking library for processing, you will probably never need to worry about the distinction between IPv4 and

IPv6. The operating system on which your Python code is running will know which IP version it is using and should

interpret addresses accordingly.

剩余368页未读，继续阅读

Up20102010

粉丝: 0
资源: 3

Python网络编程基础 第三版

Foundations of Python Network Programming, 3rd Edition.pdf 英文原版. Python网络编程基础

Foundations of Python Network Programming(3rd) 英文版pdf

Foundations of Python Network Programming, 3rd Edition.zip

foundations of python network programming

Foundations of Python Network Programming 2nd

Foundations of Python Network Programming源代码

Python网络编程基础 Foundations of Python Network Programming

Foundations of Python Network Programming_networkprogramming_

Foundations of Python Network Programming (2nd)

Foundations of Python Network Programming(Python网络编程基础)

最新资源

Python网络编程基础第三版