This is the output of the tcpdump program run on my home workstation while downloading a web page from www.theregister.co.uk. (Mostly, I wanted something that had to come a long way.)

*** Connection handshake ***

*++ My workstation sends and SYN packet advertising a window of 32120 with sequence number 1363180111 and no data.
*++ Notice that my client is using local port 3717 to connect to www (port 80) on the server.  The number 3717
*++ is the number which would be returned by the make_contact call of Chapter 3.
00:32:33.770079 desktop.home.3717 > 213.40.196.64.www: S 1363180111:1363180111(0) win 32120  (DF)

*++ The server answers with SYN, ACK, and provides its own starting sequence number, 1364976554.  The acknowledgement
*++ sequence number, 1363180112, is one more than the sequence number sent by my workstation.  This is the general rule:
*++ Ack sequence numbers is the number of the next data byte expected.
00:32:33.928292 213.40.196.64.www > desktop.home.3717: S 1364976554:1364976554(0) ack 1363180112 win 32120  (DF)

*++ Here the desktop is completing the connection with a final ack.  The tcpdump program gives all sequence number 
*++ relative after the first two packets, so packet actually contains ack number 1364976555.  (The tcpdump program
*++ simply does the subtract.)
00:32:33.928431 desktop.home.3717 > 213.40.196.64.www: . ack 1 win 32120  (DF)

*** Desktop sends the request and headers. ***

*++ Here are 107 bytes of request data.  The packet actually contains sequence number 1363180112, but tcpdump prints it
*++ as 1, since it's 1 more than the starting sequence number of 1363180111.  
00:32:33.937527 desktop.home.3717 > 213.40.196.64.www: P 1:108(107) ack 1 win 32120  (DF)

*++ The request packet is acked.  The ack number will actually be 1363180111 + 107 + 1, the next number expected.
00:32:34.088915 213.40.196.64.www > desktop.home.3717: . ack 108 win 32120  (DF)

*** Server response. ***

*++ First block of 1448 bytes of data, and its ack by the workstation.  The advertisement has gone down by 264.  Why 264?
*++ I don't know.  Each packet from the server acks 108 (relative), since no additional data has been sent.
00:32:34.091039 213.40.196.64.www > desktop.home.3717: P 1:1449(1448) ack 108 win 32120  (DF)
00:32:34.091117 desktop.home.3717 > 213.40.196.64.www: . ack 1449 win 31856  (DF)

*++ Next packet and its ack.
00:32:34.091717 213.40.196.64.www > desktop.home.3717: P 1449:2897(1448) ack 108 win 32120  (DF)
00:32:34.097773 desktop.home.3717 > 213.40.196.64.www: . ack 2897 win 31856  (DF)

*++ Now packets are recieved, and a single ack sent, which covers both.
00:32:34.249730 213.40.196.64.www > desktop.home.3717: P 2897:4345(1448) ack 108 win 32120  (DF)
00:32:34.250143 213.40.196.64.www > desktop.home.3717: P 4345:5793(1448) ack 108 win 32120  (DF)
00:32:34.250218 desktop.home.3717 > 213.40.196.64.www: . ack 5793 win 31856  (DF)

*++ Two more received.
00:32:34.255597 213.40.196.64.www > desktop.home.3717: P 5793:7241(1448) ack 108 win 32120  (DF)
00:32:34.256112 213.40.196.64.www > desktop.home.3717: P 7241:8689(1448) ack 108 win 32120  (DF)
00:32:34.256186 desktop.home.3717 > 213.40.196.64.www: . ack 8689 win 31856  (DF)

*++ Two more received.
00:32:34.402397 213.40.196.64.www > desktop.home.3717: P 8689:10137(1448) ack 108 win 32120  (DF)
00:32:34.402831 213.40.196.64.www > desktop.home.3717: P 10137:11585(1448) ack 108 win 32120  (DF)
00:32:34.402903 desktop.home.3717 > 213.40.196.64.www: . ack 11585 win 31856  (DF)

*++ Two more received.
00:32:34.403508 213.40.196.64.www > desktop.home.3717: P 11585:13033(1448) ack 108 win 32120  (DF)
00:32:34.408278 213.40.196.64.www > desktop.home.3717: P 13033:14481(1448) ack 108 win 32120  (DF)
00:32:34.408372 desktop.home.3717 > 213.40.196.64.www: . ack 14481 win 31856  (DF)

*++ Two more received.  Window is down a little.
00:32:34.408821 213.40.196.64.www > desktop.home.3717: P 14481:15929(1448) ack 108 win 32120  (DF)
00:32:34.409394 213.40.196.64.www > desktop.home.3717: P 15929:17377(1448) ack 108 win 32120  (DF)
00:32:34.409477 desktop.home.3717 > 213.40.196.64.www: . ack 17377 win 30408  (DF)

*++ Two more received.  Application is catching up a bit:   Window is back up.
00:32:34.559082 213.40.196.64.www > desktop.home.3717: P 17377:18825(1448) ack 108 win 32120  (DF)
00:32:34.559761 213.40.196.64.www > desktop.home.3717: P 18825:20273(1448) ack 108 win 32120  (DF)
00:32:34.559831 desktop.home.3717 > 213.40.196.64.www: . ack 20273 win 31856  (DF)

*++ Two more received.
00:32:34.559980 213.40.196.64.www > desktop.home.3717: P 20273:21721(1448) ack 108 win 32120  (DF)
00:32:34.567752 213.40.196.64.www > desktop.home.3717: P 21721:23169(1448) ack 108 win 32120  (DF)
00:32:34.567885 desktop.home.3717 > 213.40.196.64.www: . ack 23169 win 31856  (DF)

*** Closing, with a retransmission.

*++ Here the server is attempting to send the last chunk of data and close the connection, but this packet is out of
*++ order: Note the missing sequence numbers.
00:32:34.567773 213.40.196.64.www > desktop.home.3717: FP 24617:24792(175) ack 108 win 32120  (DF)

*++ The workstation responds with the correct ack for the data it has actually received.
00:32:34.567971 desktop.home.3717 > 213.40.196.64.www: . ack 23169 win 31856  (DF)

*++ The missing packet arrives, most likely a re-transmit (though we really don't know).
00:32:34.568513 213.40.196.64.www > desktop.home.3717: P 23169:24617(1448) ack 108 win 32120  (DF)

*++ The workstation now acks both the these packets: the re-transmit and the one which arrived out of order.
00:32:34.568590 desktop.home.3717 > 213.40.196.64.www: . ack 24793 win 30408  (DF)

*++ The workstation now responds to the earlier FIN with a FIN/ACK, with no data.
00:32:34.589552 desktop.home.3717 > 213.40.196.64.www: F 108:108(0) ack 24793 win 31856  (DF)

*++ The server finalizes with an ack.
00:32:34.755175 213.40.196.64.www > desktop.home.3717: . ack 109 win 32120  (DF)