AWS - jjin-choi/study_note GitHub Wiki

Reference

• http://www.kocw.net/home/m/cview.do?cid=6166c077e545b736
• http://www.kmooc.kr/courses/course-v1:SKKUk+SKKU_26+2019_T2/about
• https://covenant.tistory.com/222

Interview

• https://dearbest.tistory.com/6
• LP

Contents

• Dev
• Network
• Storage
• Security
• Database
• Virtualization

DevOps

• Development (개발) 과 Operations (운영) 이 합쳐진 단어로 하나의 아이디어 (새로운 소프트웨어 기능, 개선 요청 또는 버그 수정 등) 가 사용자에게 가치를 제공할 수 있도록 운영 환경에서 개발부터 배포로 진행되는 프로세스의 속도를 높이는 접근 방식을 의미한다.

• 현재 작업 수행 방식을 넘어서는 프로세스 변경이 필요함에 따라, 수행하는 작업도 변경될 수밖에 없다. DevOps는 기존의 동일한 모놀리식 소프트웨어의 개발을 가속화하는 것뿐 아니라 이러한 지속적인 개발 흐름에 더욱 적합한 새로운 종류의 소프트웨어를 개발하는 것과 관련이 있다.

• 이런 이유로 DevOps 팀이 [마이크로서비스] 아키텍처를 사용하여 소프트웨어를 구축하고 [API] 로 이러한 서비스를 함께 연결하는 경우가 많다. DevOps 팀이 각각의 기능을 더 작은 단위로 구축함으로써 서비스를 보다 신속하게 제공 가능하므로 이러한 서비스와 API가 관리되는 방식에 중점을 두고 이 모두를 통합할 수 있는 애자일 통합과 같은 전략을 수립해야 한다.

Network

1. 컴퓨터 네트워크 기본 1

• network edge 에 사용자가 위치하고 network core 에 라우터가 위치.

  • network edge: applications and hosts
  • network core: routers, network of networks
  • access networks, physical media communication links

• The network edge

  • end systems (hosts): run application programs (e.g. web, email).
  • client/server model: client host requests, receives service from always-on server.
    • (client) 자기가 원할 때 link 에 연결해서 서버로부터 정보를 가져오는 요소.
    • (server) 24 시간 연결되어 있어서 client 로부터의 요청을 기다리는 요소.
  • peer-peer model

• The network edge: connection-oriented service

  • goal: data transfer between end systems.
  • TCP (Transmission Control Protocol): connection-oriented service 를 제공하는 통신 방법.
    • client 에게 다음과 같은 내용을 제공한다.
    • reliable, in-order byte-stream data transfer. 메시지를 빠뜨리지 않고 순서대로 도착한다.
    • flow control: sender won't overwhelm receiver. sender 가 데이터를 보낼 때 receiver 에게 알맞은 속도로 조절하여 전달해준다.
    • congestion control: sender slow down sending rate when network. 네트워크 상황에 맞게 전달한다.
    • computing resource, networking resource 가 많이 소요된다.

• The network edge: connectionless service

  • goal: data transfer between end systems.
  • UDP (User Datagram Protocol)
    • connectionless
    • unreliable data transfer
    • no flow control
    • no congestion control
    • 데이터가 안정적으로 잘 전송되는지 상관없이 보내기만 하고 싶다면 UDP 를 써도 좋다.
    • 음성 전화는 몇 개 정도 유실되어도 사람들이 감지를 못하기 때문에 UDP 를 사용해도 된다.
    • 대부분의 경우는 reliable 한 게 필요하므로 TCP 를 사용한다.
  • packet: 편지 봉투처럼 메시지가 담긴 것.

• What's a protocol?

  • All communication in Internet coordinated by protocols.

• The network core

  • mesh of interconnected routers
  • 출발지에서 목적지까지 데이터를 어떻게 전달을 할까?
  • the fundamental questions: how is data transferred through net?
    • circuit switching: 출발지에서 목적지까지 가는 길을 미리 예약을 해두고 특정 사용자만 사용하도록. 예전 유선 전화망이 이 방식을 사용.
    • packet-switching: statistical multiplexing. packet 단위로 받아서 그 때 그 때 올바른 방향으로 전송하는 방식.

• Packet switching versus circuit switching

  • router 에서 나타는 데이터의 bandwidth 가 1 Mbps 라고 하면 (초당 1Mbits)
    • 각 user 은 internet 을 사용할 때 100 Kbps 데이터를 보낸다고 가정.
    • 이를 circuit switching 을 사용하면 최대 10 명까지 user 만 지원해 줄 수 있다.
    • packet switching 은 최대 사용자는 제한이 없음.

• How do loss and delay occur?

  • packets queue in router buffers.
  • packet 을 받고 다음 packet 을 받기 까지 얼마 만큼의 delay 가 생길까?

• Delay in packet-switched networks

  • 1. nodal processing: 목적지를 확인하고 output link 를 결정
  • 2. queueing: 만약 user requests 가 bandwidth 보다 클 경우에는 임시 저장 buffer 혹은 queue 라 불리우는 저장 장소가 존재한다. 따라서 outgoing edge 에서 기다리는 시간이 존재할 수 있다.
    • 사람들이 인터넷을 사용하는 pattern 에 따라 delay 가 달라질 수 있다.
  • 3. transmission delay: 첫번째 bit 가 전송된 시점부터 마지막 bit 가 전송 완료된 시점까지 걸린 시간.
    • R: link bandwidth (bps)
    • L: packet length (bits)
    • time to send bits into link = L/R
    • router bandwidth 가 pipe 이고 packet 이 양동이라고 하면 양동이에 담긴 물을 pipe 로 넣어 보낼 때 pipe 가 좁으면 시간이 오래 걸리고 pipe 가 넓으면 시간이 조금 걸린다.
    • router bandwidth 을 높이기 위해 케이블을 넓은 것으로 교체하는 방법.
  • 4. propagation delay: 마지막 bit 가 link 에 올라와서 다음 router 에 도달할 때까지 걸린 시간. 단순히 전자기파 속도. 빛의 속도. link 길이를 빛의 속도로 나눈 것. 길면 delay 가 길고 link 가 짧으면 delay 가 짧아진다.
    • d: length of physical link
    • s: propagation speed in medium
    • propagation delay = d/s
  • s and R are very different quantities !!!
  • 

• network 상에서는 queue 보다 더 많이 packet 이 들어오면 데이터가 loss 되는데 TCP 에서는 어떻게 reliable 할 수 있을 것인가?

  • 유실이 있기 마련이므로 재전송을 해주어야 한다.
  • 그럼 누가 재전송을 할 것인가? 직전 router 가 재전송 해주는 방법이 있을 것이고 다시 처음부터 재전송해주는 방법이 있을 수 있다.
  • TCP 는 가장 처음 위치에 있는 router 가 재전송을 담당한다.
    • 가장 처음 router 에 모든 client edge 정보를 가지고 있고 나머지는 전달만 한다.
    • 중간에 있는 router 은 빨리 전송하는 것만을 목적으로 한다.
    • 현재 internet 디자인은 모든 기능적인 메커니즘을 edge 에서 하고 dump core 에서는 단순 전송만 담당하도록.

2. 컴퓨터 네트워크 기본 2

• (Review) Four sources of packet delay: packet 이 중간에 여러 router 을 거쳐서 전송되는데 이 때 router 가 packet 을 받아서 알맞은 방향으로 전달하는 과정에서 delay 가 발생한다.

  • delay 분류
    • nodal processing delay: packet 을 검사하는데 걸리는 시간 (최종 목적지는 어디인지, 다음 router 는 무엇일지)
    • queueing delay
    • transmission delay
    • propagation delay
  • 한 번에 동시에 많은 사용자가 router 에 packet 을 보낼 경우에 문제가 발생할 수 있으며 일부는 queue 에 packet 이 쌓이겠지만, queue 보다 더 많은 packet 이 들어오게 되면 packet loss 가 일어난다.

• 2.1. Principles of network applications

  • 
  • Application (HTTP) -> Transport (TCP, UDP) -> Network (IP) -> Data Link layer (WiFi, LTE/3G, Ethernet)
  • 각 계층에는 다양한 protocol 이 존재하며 각 계층에서 중요한 protocol 에 대해서 알아볼 예정.
    • 하위 계층에서 상위 계층에게 service, 기능을 제공한다.
    • 즉 Application 은 하위 계층인 Transport 에서 제공하는 기능을 사용할 수 있다.
  • Client-Server architecture
    • 인터넷 상 존재하는 computer 은 고유한 주소 (IP address) 를 갖고 있음.
    • 그 중에서 server 은 permanent IP address 를 갖고 있어야 한다.
    • 반대로 client 는 고정되어 있지 않아도 된다.
  • Processing communicating
    • process: program running within a host.
    • 하나의 컴퓨터 내에서 inter-process communication (IPC) 즉 프로세스 간 통신을 위해서 OS 가 system call, 즉 interface 를 만들어 두었다.
    • 지금 다루는 내용은 다른 hosts 사이의 프로세스 간 통신을 말하며 이는 exchanging message 로, 즉 Socket (interface) 을 이용하여 통신한다.
  • Socket
    • Host1 과 Host2 의 Process1 그리고 Process2 가 서로 통신하기 위해서는 사전에 Host1 과 Host2 가 연결되어 있어야 한다. 연결시키려면 Process1 이 Process2 의 socket 과 연결하고 싶다는 의사표현을 하기 위해서는 Process2 socket 의 주소를 알고 있어야 한다. Process2 socket 의 주소 역할을 하는 게 바로 IP address + Port number 조합이다.
    • IP address 는 인터넷 상에 존재하는 Host 의 주소이고 해당 Host 에 여러 Process 가 있을텐데 특정 프로세스를 지칭할 때 Port 가 사용된다.
    • 예를 들어 naver 웹 브라우저에 접속하고자 한다면, X.X.X.X:80 이라는 IP address + port 를 입력해야 하지만, 이를 외우기 어렵기 때문에 알파벳 주소인 www.naver.com 으로 접속하고 이렇게 입력될 경우 DNS (IP 주소만 번역해 주고 port number 은 동일한 80 으로 약속) 에 의해서 해당 IP address + port 로 접속된다.
    • 모든 웹 서버는 80 번의 port 을 사용한다.
  • What Transport service does an Application need?
    • data integrity: 데이터 무결성
    • timing: 시간에 대한 희망 사항
    • throughput: 1초에 어느정도의 정보량이 도달해야 한다는 의미. (packet 이 특정 시점에 몰아서 한번에 전송되거나 나뉘어 전송되거나 동일. 예를 들어 영화 다운 로드 같은 경우)
    • security
    • 실제 Transfort 에서 제공하는 기능은 data integrity 서비스만 제공하며 (TCP) 나머지 timing, throughput, security 는 현재 제공해주지 않는 기능이다.
    • 따라서 security 가 제공되지 않기 때문에 Application layer 에서 application 을 통해 구현해야 한다.

• 2.2 Web and HTTP (HyperText Transfer Protocol)

  • HTTP: Hypertext 을 전달하는 protocol
    • Hypertext: 다른 텍스트를 지칭하는 링크가 존재하는 텍스트
    • request: 원하는 hypertext file 이름
    • response: 해당 hypertext file 전달
    • Application layer 의 HTTP 를 위해서는 Transport layer 의 TCP 를 사용하기 위해 사전에 연결을 해주어야 한다.
    • HTTP is "stateless": HTTP 는 정말 단순해서 request 에 해당하는 파일을 읽어 보내는 역할만 한다. 즉 상대방에 대한 상태를 기억하지 않음.
    • server maintains no information about past client requests.
  • HTTP connections: TCP 를 사용하는 방식에 따라서 2가지로 나누어진다.
    • TCP connections 을 만들고 HTTP 로 message 을 주고 받은 후 TCP connection 을 재사용하는지, 혹은 끊는지에 따라서 아래와 같이 나누어짐.
    • non-persistent HTTP: at most one object sent over TCP connection, then closed.
    • persistent HTTP: multiple objects can be sent over single TCP connection between client, server
  • Non-Persistent HTTP
    • 어떤 URL 에 text 와 10 개의 jpeg image 에 대한 reference 가 있다고 가정한다면,
    • 1. 가장 먼저 TCP connection 을 한다.
    • 2. hypertext file 에 대한 request / response 가 일어난다.
    • 3. TCP connection 을 closed 한다.
    • 4. 그 다음에 10 개의 jpeg image 에 대한 reference 도 읽어서 가져와야 한다.
    • 5. 1. ~ 3) 을 다시 반복한다.
  • Non-Persistent HTTP: response time
    • RTT: time for a small packet to travel from client to server and back
  • 실제로는 1개의 hypertext file 만 주고 받으면 너무 오래 걸리기 때문에 pipeline 처럼 여러개를 한번에 전송하고 한번에 받는 방식으로 진행된다.

• 2.3 FTP

• 2.4 Eletronic mail (SMTP, POP3, IMAP)

• 2.5 DNS

• 2.6 P2P application

• 2.7 Socket programming with UDP and TCP

3. Application Layer

• Socket

  • 현재 OS 에는 Transport Layer 에는 TCP 혹은 UDP 만 구현되어 있다. 둘 중 하나를 선택하여 해당 socket 을 사용하여 Application Layer 는 통신을 하게 된다.
  • TCP Socket 에 데이터를 쓰면 TCP 를 사용하는 것이고 UDP Socket 에 데이터를 쓰면 UDP 를 사용하는 것.
  • TCP Socket 은 SOCK_STREAM 이라 불리우고 UDP 는 SOCK_DGRAM 이라고 불리운다.

• Big picture: Socket functions (API)

  • TCP Server
    • socket(): web server 가 socket 을 생성한다.
    • bind(): 방금 생성한 socket 을 특정 port 에 bind 하겠다는 의미.
    • listen(): 이 socket 용도를 listen 하는데 사용하겠다. (server 이므로)
    • accept(): client 로부터 요청을 받을 준비가 되었다는 의미.
    • 여기까지 수행이 되면 client 로부터 connection 이 올 때까지 server 는 blocking 이 된다. (수동적)
  • TCP Client
    • socket(): socket 을 열고
    • connect(): 원하는 process 에 connect 하겠다는 의미.
  • Connection 을 끊을 때에는 TCP Client 에서 close() 를 하고 TCP Server 가 이를 read() 한 후에 close() 한다.

• Socket Creation and Setup

  • Function: socket()
    • int socket(int domain, int type, int protocol);
    • type: SOCK_STREAM for TCP, SOCK_DGRAM for UDP
  • Function: bind()
    • int bind(int sockfd, struct sockaddr* myaddr, int addrlen);
  • Function: listen()
    • int listen(int sockfd, int backlog);
    • backlog: 동시에 request 가 여러 개 들어오면 최대 몇 개를 처리할 것인지
  • Function: accept()
    • int accept(int sockfd, struct sockaddr* cliaddr, int* addrlen);
    • accept is blocking: accept 가 수행되면 blocking 이 되었다가 client 로부터 connection 요청이 들어오면 수행이 되면서 return 이 된다.
    • return 이 될 때 client ip 와 port 가 저장이 된다.

• Tearing Down a connection (TCP)

  • Function: close()
    • socket 사용이 끝난 이후에 close 할 때

• Multiplexing and Demultiplexing

  • 컴퓨터 Application layer 에 많은 프로세스들이 있는 상황에 각자 socket 을 갖고 있는 상황에서 Transport layer 은 Application layer 로부터 받은 message 를 segment 로 만들어 아래 layer 로 보내주어야 한다. 이를 Multiplexing 이라고 한다.
  • Receiver 측면의 Transport layer 에서 segment 를 Application layer 의 여러 socket 중에 받아야 할 socket 으로 보내주는 것이 Demultiplexing 이다.
  • Segment 는 data + header 로 구성된다. header 내에 field 가 있고 이 중에 source port #, dest port # 이 나와있다. (각각 16 bits)
  • UDP 의 경우 demultiplexing 부터 살펴보자. Connectionless demux (UDP) 이므로 모두 UDP socket 을 열어둔 상태이다.
    • Transport layer 에서의 segment 의 header 에는 source port, dest port 가 적히고 Network layer 에서의 packet 의 header 에 목적지의 IP address 가 적힌다.
    • 서로 다른 server 에서 오더라도 모두 같은 port, socket 으로 들어간다. (같은 process 로 들어간다는 의미)
    • UDP 를 사용하는 경우에는 demultiplexing 이 destination IP + destination Port 만을 사용해서 어떤 socket 으로 올릴지 demultiplexing 이 이루어진다.
  • TCP 의 경우 demultiplexing 을 살펴보자. Connection-oriented demux (TCP)
    • source IP, source port, destination IP, destination port 4 개의 값을 기반으로 어떤 socket 으로 올릴지 demultiplexing 이 이루어진다. 이 4 개 값 중 1개라도 다를 경우에는 다른 socket 으로 전송된다.
    • destination IP, destination port 가 동일하다고 할지라도 demultiplexing 의 결과로 모두 다른 socket 으로 전송될 수 있다.
    • 즉 connection-oriented 라고 볼 수 있는데 그 이유는 특정 IP address 로부터의 process 는 항상 특정 socket 으로.
    • UDP 는 어느 누구와 연결된 socket 이 있는게 아니라 destination IP, port 만 맞으면 아무나 다 받을 수 있다.
    • 따라서 해당 process 의 thread 가 각각의 socket 을 담당한다. 따라서 자원을 많이 소모한다.
    • 어쨌든 TCP, UDP 는 multiplexing 과 error checking 을 해준다.

• UDP (User Datagram Protocol)

  • Segment header field 는 4 개 밖에 없음. 동작이 단순하다.
    • fields: source port number (16 bits), dest port number (16 bits), length (16 bits), checksum (16 bits)
    • checksum: 실제 담긴 data 를 전송하는 도중에 에러가 있었는지 없었는지 확인해 주는 field.
    • 데이터에 에러가 발생한 경우에는 데이터를 올려보내지 않고 바로 drop.
    • UDP 를 통해서 message 를 받은 경우에 최소한 데이터 전송 과정에 에러가 발생하지는 않았다는 것을 보장.

• TCP 처럼 Reliable 하게 어떻게 동작하는지? Reliable Data Transfer

  • Transport 아래 layers 와 라우터 사이의 통신은 사실 unreliable 한 환경이다.
    • 이로 인해 message error, message loss 두 가지 결과를 초래할 수 있다.
  • Simple Reliable Data Transfer
    • 한 번에 packet 을 1개씩만 보내는 방식.
  • Rdt 1.0
    • 가정: 완벽하게 reliable 하다고 가정 (no packet errors, no packet loss) 한다면 우리가 필요한 mechanisms 이 따로 없다.
  • Rdt 2.0
    • 가정: packet errors (no loss) 상황이라고 가정한다면, 이 에러를 처리하기 위해 어떤 mechanism 이 필요할까?
    • Error Detection: add checksum bits 으로 판단. 만약 에러가 있었다면 다시 보내달라고 요청하거나 feedback 을 주어야 한다.
    • Feedback: Acknowledgements (ACKs) / Negative Acknowledgements (NAKs). packet 을 받을 때마다 피드백을 줘야 한다.
    • Re-transmission: 재전송
  • Rdt 2.0: Can this completely solve errors?
    • feedback packet 에도 checksum 이 있어야 한다. 그래야 feedback 에도 에러가 있는지 알 수 있다.
    • feedback 에 에러가 있으면 receiver 가 제대로 받았는지 안 받았는지 알 수 없다. 따라서 재전송을 하게 되면 receiver 입장에서는 제대로 정상 받았는데 중복된 packet 이 전달될 수도 있다.
    • receiver 입장에서 새로운 정보인지 duplicate 정보인지 어떻게 알 수 있을까?
  • Rdt 2.1: Handling duplicate packets
    • sender 가 sequence number 을 packet 에 붙여서 보낸다.
    • feedback 에 에러가 있을 경우에는 무조건 재전송. 재전송을 하더라도 sequence number 가 있으므로 receiver 는 중복 정보를 처리할 수 있게 된다.
    • sequence number 은 부가적인 정보이므로 header 에 적혀서 보내질텐데, 이를 0 부터 순차적으로 증가하도록 하면 무한대로 커질 수 있다. 즉 header 크기가 매우 커질 수 있음.
    • field 의 크기는 최소화해야 함.
    • sequence number 은 2개로 충분. 번갈아 가면서 사용하면 된다. (1개의 packet 만 보내는 경우에는)
    • 요약하자면, error detection, feedback, re-transmission, sequence number 을 이용한다.
    • Receiver 은 항상 ACK / NAK 을 전송해야 한다.
  • Rdt 2.2: NAK-free protocol
    • ACK 대신에 가장 마지막으로 정상 수신한 sequence number 을 적어보내준다.
    • 즉 PKT(0) 을 받으면 ACK(0) 을 보내고, PKT(1) 을 sender 가 보냈는데 여기서 에러가 발생하여 receiver 가 이를 정상적으로 받지 못하였다면 receiver 은 또 ACK(0) 을 보낸다. 그럼 sender 은 뭔가 잘 못 전송되었다는 것을 알게 되고 PKT(1) 을 재전송한다. 그럼 ACK(1) 을 전송하고 PKT(0) 을 다시 보낼 수 있게 된다.
  • Rdt 3.0: channel with "loss" & packet errors
    • sender 입장에서 message loss 가 발생하면 아무런 response 을 받지 못한다.
    • What mechanisms do we need for packet loss? "Timer" !
    • Sender 은 packet 을 보낼 때마다 timer 을 이용하여 일정 시간이 지나면 유실 되었다고 판단하고 재전송하면 된다.
    • 그럼 얼만큼 기다려야 할까? 이는 정답이 없다. "reasonable" amount of time.
    • timer 시간이 짧으면 실제로 유실이 잃어날 수 있을 경우에 recovery 가 빠르다. 하지만 단점은 packet 이 다시 전송될 수 있어서 network 에 overhead 를 줄 수 있다.
    • timer 시간이 길면 network overhead 를 줄일 수 있지만 loss 가 발생했을 때 반응이 늦어지게 된다.
    • timer 을 짧게 잡아서 재전송을 하게 되면 receiver 가 중복된 packet 이라 받지는 않을 거라 receiver 에 문제가 되지는 않고 network 상 overhead 가 발생하는 것.
    • sender 로부터의 packet 이 유실되거나 receiver 로부터의 packet 이 유실되거나 sender 입장에서는 동일하다.
  • Recap: Principles of Reliable Data Transfer
    • Unreliable channel 에서는 packet error, packet loss 가 발생할 수 있다.
    • Packet error 을 위한 mechanisms 은 Error detection, feedback, re-transmission, sequence number
    • Packet loss 을 위한 mechanisms 은 Timeout 이 있다.
    • 이를 위한 정보는 TCP header 의 field 로 구성되어 있다.
    • TCP 가 제공하는 기능이 reliable 한 것 말고도 많기 때문에 header 에 들어가는 정보가 많을 수 밖에 없다.
  • Performance of Rdt 3.0
    • 우리가 만든 Rdt 3.0 프로토콜은 너무 단순하다. 한 번에 1개의 packet 만 보내고 결과를 확인하는 식이기 때문에 결과를 받을 때까지 아무것도 하지 않는다.
  • Performance of Rdt 3.0
    • 실제 성능을 보면, 사용할 수 있을 정도는 아니다.
    • 전체 시간 중에서 sender 가 network 를 사용하는 비율이 클수록 좋다.
    • T (transmit) = L (packet length in bits) / R (transmission rate, bps)
    • U (sender utilization) = ( L / R ) / ( RoundTurnTime + L / R )
    • 이를 계산하면 1% 도 안된다. 너무나 비효율적.
  • Pipeline protocols
    • 한 번에 여러 개의 packets 을 보내고 이에 대한 결과를 받는 방식으로 진행된다.
    • 이렇게 되면 feedback, sequence number 관리가 복잡해진다.
    • 실제로 사용하는 프로토콜은 당연히 pipelining 을 하고 있다.
    • Two generic forms of pipelined protocols: go-Back-N, selective repeat

• Go-Back-N

  • Sender
    • window size 가 한 번에 보낼 수 있는 packet 의 양
    • 각각 packet 에 대하여 timer 가 달려 있다. feedback 받기 전에 (ACK 를 받기 전에) timeout 에 도달하면 window 안에 들어있는 본인 보다 큰 packet 을 포함하여 모두 다 재전송.
    • ACK(n): cumulative ACK.
    • ex) ACK(11): 11 번째까지 packet 을 잘 전송 받았다는 의미. 12 번째 packet 을 기다리고 있다는 의미.
  • Receiver
    • receiver 은 buffer 도 없고 단순히 자신이 받아야 할 sequence number 만 기다린다.
    • PKT(0) 이 도달하면 이를 Application layer 에 넘겨주고 ACK(0) 을 전송하고 이제 1 번째 PKT을 기다린다.
    • 만약 PKT(1) 보다 PKT(2) 가 먼저 도착하면 원하는 게 아니므로 ACK(0) 을 전송한다.
    • PKT(1) 이 오면 ACK(1) 을 보내고 이제 2 번째 PKT을 기다린다.
  • GBN in action (window size = 4 일 경우)
    • PKT0 ~ PKT3 까지를 Sender 가 전송하고 Receiver 가 PKT0, PKT1 은 잘 받았으니 PKT2 가 loss 된 경우 PKT3 은 discard 하고 ACK1 을 전송한다.
    • Sender 은 PKT3 까지 전송한 이후 wait 상태로 있다.
    • PKT0, PKT1 은 잘 전송되었으므로 더 이상 window 내에 있을 필요가 없다.
    • 다음 PCK4, PCK5 을 전송하지만 Receiver 은 계속 PCK2 을 기다리고 있으므로 PCK4, PCK5 도 받지 않는다.
    • PCK2 의 Timer 는 ACK 이 전달받지 않지 못하였으므로 조만간 Timer 가 timeout 에 도달한다.
    • PCK2 부터 모두 재전송 (PCK2 ~ PCK5)
    • Receiver 은 PCK2 를 받았으므로 ACK2 를 보낸다.
    • Send, Receive 사이에 loss 도 없고 error 도 없고 timeout 도 없다면 window 가 쭉 진행된다.
  • 즉, 계속 진행이 되다가 (Go) 유실 상황이 발생하여 timeout 이 발생하면 window size N 만큼 돌아와서 (N back) 재전송하고 다시 Go.
    • Sender 는, window 안에 들어있는 packet 은 buffer 에 들고 있어야 한다. 왜냐면 window 안에 있는 packet 은 아직 receiver 가 받았는지 안 받았는지 확신하지 못한 상황이기 때문이다.
    • 단점은 1개가 유실되었는데 window size N 만큼이 다시 보내져야 한다.

• Selective Repeat

  • Selective 하게 repeat 하는 방식
    • 이제는 ACK 가 cumulative 하면 안된다. 만약 ACK11 이라면 PKT11 을 잘 받았다는 의미로 봐야 한다.
    • 따라서 Receiver 가 자신이 기다리고 있지 않는 PKT 를 받더라도 이를 저장할 수 있도록 Receiver 측에 Buffer 가 필요하다.
    • Sender 은 ACK 을 전달 받으면 해당 PKT 의 Timer 을 해제한다.
    • Timer 가 해제되지 않은 PKT 는 Timeout 에 도달하고 Sender 는 이를 다시 재전송한다.
    • 재전송된 PKT 를 받은 Receiver 가 Buffer 에 저장하고 ACK 를 보낸다.
  • Dilemma
    • Sequence number 가 계속 늘어나면 header 가 계속 커지므로 좋지 않다.
    • 그럼 어떻게 최소한의 범위로 사용할 수 있을까?
    • window size = 3 이면 sequence number 개수는? 4개로 해보자.
    • PKT 순서: 0 1 2 3 0 1 2 3 0 1 2 3
    • sender 가 0 1 2 를 한 번에 보낼 수 있다. 그런데 Receiver 가 이를 모두 전달 받았고 ACK 를 전송하는 과정에서 ACK0 ACK1 ACK2 가 모두 유실되었다고 하면, Sender 의 PKT0 PKT1 PKT2 의 Timer 가 모두 timeout 되어 0 부터 다시 재전송을 한다.
    • Receiver 는 이미 0 ~ 2 까지는 전달 받았기 때문에 3 을 기다리고 있는 상황이고 재전송된 0 ~ 2 가 3 번 다음으로 들어온 PKT 이라고 생각하여 이를 Buffer 에 저장한다. 그런데 사실 이는 Duplicated pkt 이다.
    • 따라서 window size = N 일 때 buffer 크기가 N + 1 이면 문제가 생긴다.
    • sequence number 범위를 늘리면 해결이 되지만 그럼 새로운 packet 과 duplicate packet 을 구분할 수 있는 최소의 범위는 얼마일까?
    • 모든 packet 에 timer 을 달아야 하는 단점.
    • 동시에 수행되는 process 개수가 매우 많은데 모두 TCP connection 을 가지고 있고 이게 모두 timer 을 가지고 있다면 실제로 적용이 어려움.

• 복습

  • Application layer (message)
  • Transport layer - TCP (segment): segment = header (meta data) + data (message)
  • Network layer - IP (packet): packet = header + data (segment)
  • Link layer: frame = header + data (packet)

• Connection-Oriented transport: TCP

  • Overview

    • point-to-point: one sender, one receiver. 한 쌍의 sockets (1 개의 socket 과 1 개의 socket) 간 통신을 책임진다. process 1개에 socket 이 여러개 있을 수 있는데 이 중에서도 1 개의 socket 와 1개의 socket 의 통신.
    • reliable, in order byte stream: 유실되지 않고 순서대로
    • pipelined: window size 를 설정하여 사용
    • send & receive buffers: sender 이면서 receiver. sender buffer 은 재전송하기 위해서. receive buffer 은 out of order 로 들어온 데이터를 순서대로 저장하기 위해.
    • full duplex data: 데이터가 양방향으로 진행된다. 즉 sender 만 하는 server 가 있는게 아니라 sender 이면서 receiver 이라는 의미.
    • connection-oriented: handshaking
    • flow controlled: receiver 의 소화 능력에 맞게 보내주어야 한다.
    • 내부 네트워크 상황이 받아들일 수 있는 만큼만

  • TCP Segment Structure - header

    • source port number (16 bits), destination port number (16 bits)
    • sequence number (32 bits)
    • acknowledgement number (32 bits)
    • receive window (16 bits): receive buffer 에 얼만큼의 여유가 있는지 알려주기 위한
    • checksum (16 bits): 전송되는 동안 에러가 발생했는지 확인하기 위한 용도

  • TCP sequence number's and ACKs

    • Host A 와 Host B 가 있는 상황에서 'C' character 1 byte 을 보내고자 한다. (전송계층2 16:15)

  • Reliable Data Transfer

  • Flow control

  • Connection management