Python网络编程入门指南

需积分: 10 118 浏览量更新于2024-07-20 4 收藏 3.73MB PDF 举报

"Python网络编程基础" 本书《Python网络编程基础》是针对Python编程语言在网络应用方面的入门指南，适合不同层次的Python开发者、Web开发者以及网络程序员作为参考书籍。书中介绍的技术在实际工作环境中具有很高的实用价值，能帮助读者深入理解和应用Python进行网络编程。全书共分为18章，覆盖了网络编程的基础到高级主题： 1. 第1章介绍了客户端-服务器网络的基本概念，这是网络编程的基础，包括网络通信的基本原理和架构。 2. 第2章深入讲解了用户数据报协议（UDP），这是一种无连接的传输协议，适用于实时数据传输和对高效率有要求的应用。 3. 第3章则探讨了传输控制协议（TCP），一种面向连接的、可靠的传输协议，适用于需要稳定数据传输的场景。 4. 第4章介绍了套接字名称和域名系统（DNS），解释了如何通过套接字进行网络通信，并解析域名以获取IP地址。 5. 第5章涵盖了网络数据和网络错误处理，讨论了如何有效地处理网络数据的传输和可能出现的错误。 6. 第6章讲解了安全套接层/传输层安全（TLS/SSL），它是网络安全的重要组成部分，用于加密网络通信，确保数据传输的安全性。 7. 第7章涉及服务器架构，包括服务器的设计模式和并发处理策略。 8. 第8章介绍了缓存和消息队列，这些是提高网络应用程序性能和可靠性的关键工具。 9. 第9章和第10章分别阐述了HTTP客户端和服务器的实现，对于Web开发人员来说，这两章尤其重要。 10. 第11章深入讨论了万维网（World Wide Web）的工作原理，包括HTTP协议和相关技术。 11. 第12章至第15章涵盖了电子邮件的构建、解析、SMTP（简单邮件传输协议）、POP（邮局协议）和IMAP（因特网消息访问协议），这些都是电子邮件服务的核心技术。 12. 第16章和第17章分别讲解了Telnet和SSH（安全外壳协议），用于远程登录和管理，确保了网络连接的安全性。 13. 第18章探讨了远程过程调用（RPC），这是一种使程序能够通过网络调用另一台计算机上的程序的方法。书后的索引方便读者快速查找所需信息。作者John Goerzen和莫迟的专业知识使得本书内容深入浅出，易于理解，是学习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页未读，继续阅读

colorsky100

粉丝: 22
资源: 7

Python网络编程入门指南

python网络编程基础

PYTHON网络编程基础

python网络编程教程pdf

学习python网络编程的有效方法

python网络编程第三版pdf

python 3 网络编程基础

python网络编程讲解

python学习网络编程有什么用

python进阶编程 pdf

python的网络编程123

最新资源