fix some typo 2

credit_flow.md

@@ -116,7 +116,7 @@ reader <--[grant]-- channel <--[grant]-- queue process <--[grant]--message store
 ```
 
 Having one channel and one queue process makes things easier to
-undertand but it might not reflect reality. It’s common for RabbitMQ
+understand but it might not reflect reality. It’s common for RabbitMQ
 users to have more than one channel publishing messages on the same
 connection. Even more common is to have one message being routed to
 more than one queue. What happens with the credit flow scheme we’ve

interceptors.md

@@ -7,7 +7,7 @@ development of the
 [Sharding Plugin](https://github.com/rabbitmq/rabbitmq-sharding/blob/master/README.extra.md#intercepted-channel-behaviour)
 to facilitate mapping queue names as specified by users vs. the actual
 names used by sharded queues. Another plugin using interceptors is the
-[Message Timestam Plugin](https://github.com/rabbitmq/rabbitmq-message-timestamp)
+[Message Timestamp Plugin](https://github.com/rabbitmq/rabbitmq-message-timestamp)
 which injects timestamps into message properties during
 `basic.publish`.
 

networking_and_connections.md

@@ -136,7 +136,7 @@ cleaned up.
 `rabbit_queue_collector` is a `gen_server` which handles the above.
 
 
-## STOMP Connetion Process Tree
+## STOMP Connection Process Tree
 
 For STOMP, TCP listener and Ranch supervision tree is similar to
 that of AMQP 0-9-1 (see above) except that the `tcp_listener_sup` supervisor

publisher_confirms.md

@@ -21,7 +21,7 @@ information.
 The first one is a
 [dtree](https://github.com/rabbitmq/rabbitmq-server/blob/master/src/dtree.erl)
 stored in the field `unconfirmed`, which keeps track of the `MsgSeqNo`
-associated with the QPids to to which the message was delivered and
+associated with the QPids to which the message was delivered and
 the Exchange Name used to publish the message. As explained in the
 _dtree_ documentation, entries on the _dual-index tree_ are stored
 using a primary key, a set of secondary keys, and a value. In the case

queues_and_message_store.md

@@ -10,7 +10,7 @@ Startup
 
 The queue's supervisor initially starts the process as
 rabbit_prequeue. This is a gen_server which determines whether the
-process is a an HA slave or a regular queue or master (see HA
+process is an HA slave or a regular queue or master (see HA
 documentation), and if so whether it is starting afresh or needs to
 recover. This then uses the gen_server2 "become" mechanism to become
 the correct sort of process - for this document we'll deal with