1 / 58

CMU SSD8: Networks Tools and FTP Protocols

CMU SSD8: Networks Tools and FTP Protocols. Tan Yi Software College Northwestern Polytechnical University. Network Tools ( 常用的网络工具 ). Netstat Ping/tracert Nslookup. netstat. displays the contents of various net- work-related data structures. The options have the following meaning:

osma
Download Presentation

CMU SSD8: Networks Tools and FTP Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CMU SSD8: Networks Tools and FTP Protocols Tan Yi Software College Northwestern Polytechnical University

  2. Network Tools (常用的网络工具) • Netstat • Ping/tracert • Nslookup

  3. netstat • displays the contents of various net- work-related data structures. • The options have the following meaning: • -a With the default display, show the state of all sockets; normally sockets used by server processes are not shown. • -s Show per-protocol statistics.

  4. Ping/tracert • ICMP • Traceroute

  5. FTP 文件传输协议(File Transfer Protocol) Reference: RFC 959

  6. FTP 目标 Objectives(摘录于RFC 959) • promote sharing of files • encourage indirect use of remote computers • shield user from variations in file storage • transfer data reliably and efficiently • “FTP, although usable directly by a user at a terminal, is designed mainly for use by programs”

  7. HTTP 与 FTP的比较 • 都是文件传输协议，TCP • FTP使用两个并行的TCP连接control connection, data connection. • FTP的控制信息是out-of-band • HTTP是带内in-band传输信息

  8. The FTP Model

  9. FTP client (客户机) 首先与 server(服务器)在21号端口上建立一个用于控制的TCP连接。 • FTP client

  10. Control and Data Connections • Control functions (commands) and reply codes are transferred over the control connection. • All data transfer takes place over the data connection. • The control connection must be “up” while data transfer takes place.

  11. Control Connection • The control connection is the “well known” service. Port 21 • The control connection uses the TELNET protocol. • Commands and replies are all line oriented text (default is ASCII).

  12. Standard Connection Model A Control B Data

  13. Alternative Connection Model Control Control A B C Data

  14. Access Control Commands USER specify user 用户名 PASS specify password 口令 CWD change directory 换目录 CDUP change directory to parent 上一级目录 QUIT logout 退出

  15. Transfer Parameter Commands PORT publish local data port PASV server should listen TYPE establish data representation MODE establish transfer mode STRU establish file structure

  16. Service Commands RETR retrieve file SORT send file STOU send file and save as unique APPE send file and append ABOR abort prev. service command PWD print working directory LIST transfer list of files over data link

  17. FTP Replies • All replies are sent over control connection. • Replies are a single line containing • 3 digit status code (sent as 3 numeric chars). • text message. • The FTP spec. includes support for multiline text replies.

  18. FTP Reply Status Code example • 331 Username OK, password required • 125 Data connection already open; transfer starting • 425 Can’t open data connection • 452 Error writing file

  19. FTP Reply Status Code First digit of status code indicates type of reply: ‘1’: Positive Preliminary Reply (got it, but wait). ‘2’: Positive Completion Reply (success). ‘3’: Positive Intermediate Reply (waiting for more information). ‘4’: Transient Negative Completion (error - try again). ‘5’: Permanent Negative Reply (error - can’t do).

  20. FTP Reply Status Code • 2nd digit indicates function groupings. ‘0’: Syntax (problem with command syntax). ‘1’: Information (reply to help or status cmds). ‘2’: Connections (problem with a connection). ‘3’: Authentication (problem with login). ‘4’: Unspecified. ‘5’: File system (related to file system). • 3rd digit indicates specific problem within function group.

  21. Data Transfer Modes • STREAM: file is transmitted as a stream of bytes. • BLOCK: file is transmitted as a series of blocks preceded by headers containing count and descriptor code (EOF, EOR, restart marker). • COMPRESSED: uses a simple compression scheme - compressed blocks are transmitted.

  22. RFC 959 • The RFC includes lots more information and many details including: • parameters for commands • lists of reply status codes • protocol state diagrams • support for a variety of file structures • sample sessions

  23. TFTPTrivial File Transfer Protocol References: RFC 783, 1350

  24. TFTP Usage and Design • Transfer files between processes. • Minimal overhead (no security). • Designed for UDP, although could be used with many transport protocols.

  25. TFTP Usage and Design (cont.) • Easy to implement • Small - possible to include in firmware • Often uses to bootstrap workstations and network devices.

  26. Diskless Workstation Booting 1The call for help Help! I don't know who I am! My Ethernet address is: 4C:23:17:77:A6:03 Diskless Workstation RARP

  27. Diskless Workstation Booting 2The answer from the all-knowing RARP Server I know all! You are to be know as: 128.113.45.211 Diskless Workstation RARP REPLY

  28. Diskless Workstation Booting 3The request for instructions I need the file named boot-128.113.45.211 Diskless Workstation TFTP Request (Broadcast)

  29. Diskless Workstation Booting 4The dialog TFTP Server here is part 1 I got part 1 here is part 2 Diskless Workstation boot file TFTP File Transfer

  30. TFTP Protocol 5 message types: • Read request • Write request • Data • ACK (acknowledgment) • Error

  31. Messages • Each is an independent UDP Datagram • Each has a 2 byte opcode操作字 (1st 2 bytes) • The rest depends on the opcode.

  32. FILENAME MODE DATA ERROR MESSAGE Message Formats OPCODE 0 0 OPCODE BLOCK# OPCODE BLOCK# OPCODE BLOCK# 0 2 bytes 2 bytes

  33. Read Request 02 filename 0 mode 0 null terminated ascii string containing name of file null terminated ascii string containing transfer mode 2 byte opcode network byte order variable length fields!

  34. Write Request 02 filename 0 mode 0 null terminated ascii string containing name of file null terminated ascii string containing transfer mode 2 byte opcode network byte order variable length fields!

  35. TFTP Data Packet 03 block # data 0 to 512 bytes 2 byte block number network byte order 2 byte opcode network byte order all data packets have 512 bytes except the last one.

  36. TFTP Acknowledgment 04 block # 2 byte block number network byte order 2 byte opcode network byte order

  37. TFTP Error Packet 05 errcode errstring 0 null terminated ascii error string 2 byte opcode network byte order 2 byte error code network byte order

  38. TFTP Error Codes 0 - not defined 1 - File not found 2 - Access violation 3 - Disk full 4 - Illegal TFTP operation 5 - Unknown port 6 - File already exists 7 - No such user

  39. TFTP transfer modes • “netascii” : for transferring text files. • all lines end with \r\n (CR,LF). • provides standard format for transferring text files. • both ends responsible for converting to/from netascii format. • “octet” : for transferring binary files. • no translation done.

  40. NetAscii Transfer Mode Unix - end of line marker is just '\n' • receiving a file • you need to remove '\r' before storing data. • sending a file • you need to replace every '\n' with "\r\n" before sending

  41. Lost Data Packets - Original Protocol Specification • Sender uses a timeout with restransmission. • sender could be client or server. • Duplicate data packets must be recognized and ACK retransmitted. • This original protocol suffers from the "sorcerer’s apprentice syndrome".

  42. Sorcerer’s Apprentice Syndrome send DATA[n] (time out) retransmit DATA[n] receive ACK[n] send DATA[n+1] receive ACK[n] (dup) send DATA[n+1] (dup) ... receive DATA[n] send ACK[n] receive DATA[n] (dup) send ACK[n] (dup) receive DATA[n+1] send ACK[n+1] receive DATA[n+1] (dup) send ACK[n+1] (dup)

  43. The Fix • Sender should not resend a data packet in response to a duplicate ACK. • If sender receives ACK[n] - don’t send DATA[n+1] if the ACK was a duplicate.

  44. Concurrency • TFTP servers use a "well known address" (UDP port number). • How would you implement a concurrent server? • forking (alone) may lead to problems! • Can provide concurrency without forking, but it requires lots of bookkeeping.

  45. TFTP Concurrency • According to the protocol, the server may create a new udp port and send the initial response from this new port. • The client should recognize this and send all subsequent messages to the new port.

  46. RRQ (read request) • Client sends RRQ • Server sends back data chunk #0 • Client acks chunk #0 • Server sends data chunk #1 • ...

  47. WRQ (write request) • Client sends WRQ • Server sends back ack #0 • Client data chunk #1 (the first chunk!) • Server acks data chunk #1 • … there is no data chunk #0!

  48. When is it over? • There is no length of file field sent! • All data messages except the last one contain 512 bytes of data. • message length is 2 + 2 + 512 = 516 • The last data message might contain 0 bytes of data!

  49. Issues What if more than 65535 chunks are sent? • 65536 blocks x 512 bytes/block = 33,554,432 bytes. • The RFC does not address this issue! • Remember that the network can duplicate packets!

More Related