Python3网络编程实战指南

4星 · 超过85%的资源需积分: 33 121 浏览量更新于2024-07-20 7 收藏 3.71MB PDF 举报

"Python网络编程第三版是一本针对Python3的网络编程基础教程，适合初学者。本书涵盖了从客户端-服务器网络基础到高级主题如TLS/SSL、HTTP服务器和电子邮件处理等多个方面。" 在《Python网络编程第三版》中，作者深入浅出地介绍了网络编程的关键概念和技巧，使得读者能够利用Python进行有效的网络通信。书中的内容包括： 1. **客户端-服务器网络基础**：这部分内容介绍了网络通信的基本模型，即客户端和服务器之间的交互方式，以及如何使用Python的socket库创建简单的网络应用程序。 2. **UDP（用户数据报协议）**：讲解了UDP的特点和使用场景，包括如何发送和接收UDP数据包，以及它与TCP协议的主要区别。 3. **TCP（传输控制协议）**：深入讨论TCP的连接建立、数据传输和断开过程，以及TCP的可靠性和流量控制机制。还涵盖了如何使用Python的socket库实现TCP客户端和服务器。 4. **Socket命名和DNS**：介绍了IP地址、域名系统（DNS）的工作原理，以及如何在Python中进行DNS查询和解析。 5. **网络数据和网络错误**：讨论了网络数据的编码与解码，以及在网络编程中可能出现的错误类型和处理方法。 6. **TLS/SSL**：讲述了如何使用Python的ssl模块实现安全套接层（SSL）和传输层安全（TLS），以确保网络通信的安全性。 7. **服务器架构**：探讨了不同类型的服务器架构，如单线程、多线程和异步I/O模型，以及如何在Python中实现这些架构。 8. **缓存和消息队列**：介绍如何利用缓存提高性能，以及使用消息队列进行异步通信。 9. **HTTP客户端和服务器**：详细讲解了HTTP协议，如何使用Python实现HTTP客户端（如请求库）和HTTP服务器（如HTTP.server模块）。 10. **万维网（WWW）**：深入HTTP的上下文，讨论了Web的工作原理，包括URL、HTTP方法和状态码等。 11. **构建和解析电子邮件**：涵盖了邮件头的处理、MIME编码以及如何使用Python处理电子邮件的发送和接收。 12. **SMTP（简单邮件传输协议）**：讲解如何使用Python的smtplib库发送电子邮件，包括认证和附件处理。 13. **POP（邮局协议）**：介绍了如何使用Python的poplib库接收电子邮件，包括POP3协议的工作流程。 14. **IMAP（因特网消息访问协议）**：讲解了使用Python的imaplib库进行电子邮件的检索和管理，特别是IMAP4协议的使用。 15. **Telnet和SSH**：涵盖了远程终端访问的两种常见协议，如何在Python中实现Telnet客户端和SSH客户端，以及安全远程登录。 16. **FTP（文件传输协议）**：介绍了FTP的使用，包括Python的ftplib库的使用方法，以及上传和下载文件。 17. **RPC（远程过程调用）**：讲解了RPC的概念，以及如何在Python中实现简单的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.

www.it-ebooks.info

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.

www.it-ebooks.info

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'

www.it-ebooks.info

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.

www.it-ebooks.info

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.

www.it-ebooks.info

剩余368页未读，继续阅读

最好的年华

粉丝: 2
资源: 8

Python3网络编程实战指南

Python网络编程第三版 （中文版）美 布兰德·罗登 经典版

Python网络编程第三版

Python网络编程基础

python网络编程第三版pdf

python网络编程第三版（中文加英文，还附加网络编程攻略中文版）

Python网络编程第三版：深入TCP/UDP, HTTP, SMTP等协议

Flask Web开发+Python核心编程第二版+Python核心编程第三版

Python网络编程基础 第三版

Python核心编程 第三版

python网络编程(第三版)

最新资源

Python网络编程第三版（中文版）美布兰德·罗登经典版

Python网络编程基础第三版

Python核心编程第三版