http://www.kocw.net/home/search/kemView.do?kemId=1169634
컴퓨터네트워크
인터넷을 동작시키는 컴퓨터네트워크 프로토폴을 학습한다.
www.kocw.net
https://media.pearsoncmg.com/intl/ge/2021/cws/ge_kurose_compnetwork_8/cw/index.php
Companion Website | Computer Networking: A Top-Down Approach, Global Edition, 8/e
VideoNotes Video tutorials illustrating key concepts from the text.
media.pearsoncmg.com
네트워크의 구조 (TCP/IP 기준)
네트워크는 여러 레이어로 나눌 수 있으며 각 레이어에는 제공되는 여러 protocol이 있다. 아래 그림은 여러 레이어와 각 레이어에서 제공하는 유명한 protocol들을 나타낸 것이다.
각 계층들은 하위 계층의 서비스를 이용한다. 예를 들어, application 계층은 하위 계층인 transport 계층의 서비스를 사용할 수 있고 transport 계층은 하위 계층인 network 계층의 서비스를 사용할 수 있는 것이다. 따라서 한 계층이 원하는 서비스를 하위 계층이 제공하지 않으면 자신의 계층에서 해당 서비스를 구현하지 않는 이상 해당 서비스를 사용할 순 없다.
App은 Application 계층에서 동작한다. 라우터는 보통 3 계층(~network layer) 장비이므로 router들은 신경 쓰지 말고 end-system에 대해서만 생각해 보자.
Client-Server paradigm
server:
- always-on host
- 영구적인, 바뀌지 않는 주소 (주소가 바뀌면 매우 불편할 것이다. naver 주소가 매일 바뀌는 것을 생각해 보자. 우리는 매일 바뀐 naver 주소를 찾아야 할 것이다.)
client:
- 서버와 통신
- 동적 IP를 가질 수 있음
- 다른 클라이언트와 직접 대화하지 않음
예시:
- HTTP, IMAP, FTP
Peer-peer architecture
특징:
- no always-on server
- 임의의 end system 간 직접적인 소통
- peer는 다른 peer에게 서비스를 요청하고 다른 피어에게 서비스를 제공한다.
( self-scalability - 새로운 peer가 새로운 용량과 새로운 서비스 수요를 가져온다. )
예시:
- P2P file sharing
client-server를 사용하던 peer-peer를 사용하던 어쨌든 통신하는 end system 간 연결이 되어야 뭘 할 수 있을 텐데 process 간 통신에서 inter-process communication(IPC)가 있는 것처럼 end system 간 통신에서도 무언가 필요하다. 그 역할을 하는 게 바로 socket이다.
Socket
process는 socket과 메시지를 주고받는다.
socket은 문과 유사하다:
- sending process가 메시지를 문 밖으로 밀어낸다.
- sending process는 receiving process에게 메시지를 전달하기 위해 문 반대편에 있는 전송 인프라에 의존한다.
- 관련 소켓 2개가 양쪽에 하나씩 존재
Addressing processes ( 프로세스 주소 지정 )
메시지를 받으려면 프로세스에 식별자가 필요하다. host device는 32비트의 고유한 IP 주소를 갖고 있다.
택배 배달받을 때 주소(서울특별시 **로 **번지)를 적어놓는 것과 동일하다. 네트워크에서도 현실과 마찬가지로, 데이터를 받을 process가 어디에 위치해 있는지 식별할 수 있는 식별자가 필요한데 그것이 32비트 IP주소라는 것.
Q. process를 식별하는데 프로세스가 실행되는 host의 IP 주소로 충분한가요?
A. 아니요, 많은 프로세스들이 같은 호스트 안에서 실행될 수 있습니다. 한 가족이 같이 사는 경우 올바른 주소로 배달하더라도 그것이 누구 것인지를 모르는 것과 동일합니다. (일단 올바른 주소로 배달하긴 했는데, 할아버지한테 배달 온 건지, 할머니한테 배달 온 건지, 아빠한테 배달 온 건지, 엄마한테 온 건지, 딸한테 온 건지, 아들한테 온 건지는 '주소'만 보고는 알 수 없다는 것) 따라서 식별자는 IP주소와 포트 넘버가 있어야 합니다. port number란 택배의 '수령자'와 같습니다. 주소(IP 주소)와 수령자(port number)가 있으면 정확하게 그 사람에게로 배달이 가능합니다. (서울특별시 **로 **번지에 사는 김**에게 전달해 주세요.)
application 계층 프로토콜은 다음을 정의한다.
교환되는 메시지 유형(e.g. request, response)
메시지 syntax(메시지의 필드 및 필드 묘사 방법), 메시지 semantic (필드에서 정보의 의미)
process가 메시지를 보내고 응답하는 시기와 방법에 대한 규칙
application 계층이 하위 계층인 transport 계층에게 바라는 서비스들
아래 서비스들이 전부 제공되고 있지는 않고 일부 제공 중이다. 그냥 응용 계층이 '바라는' 서비스다.
data integrity (데이터 무결성)
- 데이터 무결성이란 데이터의 일관성, 정확성, 유효성이 유지되는 것을 의미한다.
- 일관성: 지금 보나 나중보나 값이 중간에 혼자 바뀌지 않는 것
- 정확성: 중복, 누락이 없는 상태
- 유효성: 유효한 데이터만 입력 가능하도록 하는 것
- 파일 전송 혹은 web transactions 등은 100% 안정적인 데이터 전송이 필요하다.
timing
- 내가 보낸 bit가 최소 내가 원하는 일정 시간 내에는 도착했으면 하는 것
- e.g., 전화의 경우 일정한 속도로 음성 패킷이 도착해야 됨 이는 일정한 timing을 요구하는 것.
throughput (처리량)
- 효과적으로 작동하려면 최소한의 처리량이 요구되는 app들이 있다. 해당 app은 이 throughput을 요구하는 것이다.
- 몇 초 안에 최소한 1mb 양의 데이터가 도착해야 한다면 이는 throughput을 요구하는 것
- e.g. 영화 다운로드
** timing과 throughput의 차이
0.999999초 까지 패킷이 하나도 도착 안 하다가 0.000001초 만에 모든 패킷이 도착지에 도착했다면 throughput은 만족시킨 것일 수 있지만 timing은 만족시키지 못한 것이다. 통화를 하는데 10초 동안 안 들렸다가 0.000001초 만에 그동안의 음성이 한꺼번에 들리면 우리는 그 말을 알아들을 수 있을까? 아마 불가능할 것이다. 다만 영화 다운로드하는데 10초 동안 하나도 다운로드되지 않다가 0.00001초 만에 다운로드가 완료된다고 문제가 될 것은 없다. 그냥 빨리 다운로드되면 그만인 것이다. throughput은 '처리량'에 관한 것이고 timing은 '꾸준한 속도'에 관한 것이다.
security
- 보안, 암호화
인터넷 transport 계층이 제공하는 서비스들
아래 서비스는 실제 transport layer가 제공하는 서비스들이다.
TCP service
reliable transport (신뢰할 수 있는 전송)
- 내가 보낸 데이터가 문제없이 목적지로 가는 것을 보장해 준다.
flow control (흐름 제어)
- receiver가 처리할 수 없을 정도의 데이터를 한꺼번에 보내지 않는다.
- receiver의 데이터 처리 능력에 따라 알맞은 속도로 전송을 한다는 것
- 예를 들어, 1초에 10만큼의 데이터 처리 능력을 갖는 receiver에게 1초에 100만큼의 데이터를 전송하면 90은 그냥 버릴 것이다. 이러한 상황을 방지/개선해준다는 것이다.
congestion control (혼잡 제어)
- 네트워크 과부하를 고려하여 데이터를 전송함
- 1초에 10만큼의 데이터만 받을 수 있는 네트워크에 1초에 100만큼을 보내면 90은 버려질 것 이러한 상황을 고려하여 데이터를 전송함.
TCP가 제공하지 않는 것
- timing
- minimum throughput guarantee
- security
UDP service
unreliable data transfer(신뢰할 수 '없는' 전송)
- 목적지에 내가 보낸 데이터가 문제없이 잘 도착하는지를 고려하지 않고 그냥 보낸다.
UDP가 제공하지 않는 것
- reliability
- flow control
- congestion control
- timing
- throughput guarantee
- security
Q. UDP는 다 지원하지 않는데 그럼 UDP는 누가 쓸까?
A. TCP가 제공하는 서비스들(reliable, flow control, congestion control)이 필요 없다면 굳이 TCP를 사용하지 않고 UDP를 사용한다. 그리고 서비스의 신뢰성보다 연속성과 성능이 중요하다면 UDP를 사용한다. 인터넷 전화의 경우 패킷 몇 개가 유실되어도 어차피 사람은 인지하지 못하고 만약 유실된 패킷을 재전송하느라 끊김이 발생한다면 통화 시 매우 불편할 것이다. 온라인 게임과 스트리밍도 비슷한 이유로 UDP를 사용한다.
Web과 HTTP
web page는 각각 다른 웹 서버에 저장될 수 있는 개체로 구성된다. 개체는 HTML 파일, JPEG 이미지, Java 애플릿, 오디오 파일 등일 수 있다. 웹 페이지는 URL로 주소를 지정할 수 있으며 여러 참조 개체를 포함하는 HTML 파일로 구성된다.
HTTP 개요
HTTP: hypertext transfer protocol
application layer의 protocol이다.
client/server model을 사용한다.
- client: 웹 개체를 요청, 수신 및 표시하는 브라우저
- server: 웹 서버는 요청에 대한 응답으로 개체를 전송
HTTP는 TCP(응용 계층 밑에 있는 전송 계층의 신뢰 전송을 보장하는 프로토콜)를 사용한다.
1. client는 서버 포트 80에 대해 TCP 연결(소켓 생성)을 시작한다. (init)
2. server는 클라이언트로부터 TCP 연결을 수락한다.
3. 브라우저(client)와 웹 서버 간 HTTP message(application 계층 프로토콜 message) 교환
4. TCP 연결 종료
HTTP는 'stateless'하다
- 서버가 client의 이전 상태를 보존하지 않는다.
- stateful의 반대 개념이다. (stateful: 서버가 클라이언트의 이전 상태를 보존)
- 예시:
<stateful>
승객: 서울에서 전주 가는 KTX는 얼마인가요?
직원: 25,000원입니다.
승객: 2장 주세요.
직원: 50,000원입니다. 결제는 무엇으로 하시겠습니까? (KTX 노선과 주문 수량에 대한 상태를 유지)
승객: 체크카드입니다.
직원: 결제과 완료되었습니다. (KTX 노선과 주문 수량, 결제 수단에 대한 상태를 유지)<stateless>
승객: 서울에서 전주 가는 KTX는 얼마인가요?
직원: 25,000원입니다.
승객: 2장 주세요.
직원: ??? 무엇을 2장 구매하시는 건가요???
승객: 아까 말했잖아요😳. 서울에서 전주 가는 KTX요!!!
직원: 몇 장인지, 결제 수단은 무엇인지 한 번에 얘기해주세요!
** state를 유지하는 프로토콜은 복잡하다
과거 이력(state)을 유지해야 하고, 서버/클라이언트가 갖고 있는 state가 서로 다를 경우 누구의 state가 옳은 것인지 확인하고 조정해야 한다.
HTTP connections: two types
Non-persistent HTTP (지속성이 없는 HTTP)
1. TCP connection open
2. TCP 연결을 통해 최대 하나의 개체 전송
3. TCP connection closed
Non-persistent HTTP: response time
- RTT (definition): 작은 패킷이 클라이언트에서 서버로 이동하고 다시 클라이언트로 돌아올 때까지 걸리는 시간
- HTTP 응답 시간
- TCP 연결을 시작할 때의 RTT
- HTTP request의 RTT
- 개체/파일 전송 시간
- 따라서 Non-persistent HTTP response time = RTT + RTT + file/object transmission time
Persistent HTTP (지속적인 HTTP)
Non-persistent HTTP는 몇 가지 단점이 있다.
- 각 요청 개체에 대한 새로운 연결이 설정되고 유지되어야 한다.
- 각 개체는 2RTT를 필요로 한다.
Persistent HTTP는 서버가 응답을 보낸 뒤에도 TCP 연결을 그대로 유지한다. 따라서 같은 클라이언트와 서버 간의 이후 요청/응답은 같은 연결을 통해 보내진다. 따라서 참조된 모든 개체에 대해 최소 1개의 RTT만 필요하다. (Non-persistent HTTP에 비해 response time이 절반으로 단축)
Persistent HTTP 순서
1. 서버와 TCP 연결
2. 클라이언트와 서버 간 단일 TCP connection을 통해 여러 개의 개체를 보낼 수 있음
3. TCP connection closed
HTTP, Stateless, Connectionless, HTTP 메시지 개념 (velog.io)
HTTP, Stateless, Connectionless, HTTP 메시지 개념
HTTP, 무상태, 비연결성, HTTP 메시지를 간략하게 알아보자🧐
velog.io
'네트워크' 카테고리의 다른 글
| 컴퓨터 네트워크 기본 5 (0) | 2023.01.09 |
|---|---|
| 컴퓨터 네트워크 기본 4 (0) | 2023.01.09 |
| 컴퓨터 네트워크 기본 3 (0) | 2023.01.07 |
| 컴퓨터 네트워크 기본 1 (0) | 2022.11.05 |
| 로드 밸런싱 (0) | 2021.07.28 |