인터넷 통신
클라이언트와 서버가 소통할 때 인터넷이라는 거대한 망을 사용해서 소통한다.
이때 소통하는 각각의 주소를 IP라고 한다.
지정한 IP 주소로 데이터를 전달하고, 이때 패킷(Packet) 단위로 데이터를 전달한다.
클라이언트와 서버는 하나의 케이블로 연결된 게 아니고, 여러 노드들을 통해서 연결된다.
패킷을 보낼 때 기존에 사용했던 노드 말고 다른 노드를 사용해 전송될 수 있어 항상 동일한 경로로 패킷을 보내지 않는다.
IP(인터넷 프로토콜)
IP 패킷 정보 : 출발지 IP + 목적지 IP + 기타 + ... + 전송 테이터
IP 프로토콜의 한계
1. 비연결성 : 패킷을 받을 목적지가 불능 상태여도 패킷이 전송된다!
2. 비신뢰성 : 패킷이 중간에 사라지거나, 패킷의 순서 보장이 안된다.
3. 동시성 : 하나의 IP에서 서버에 통신하는 애플리케이션이 둘 이상이면? 어느 게 어떤 애플리케이션 것일까?
이런 문제점을 해결하기 위한 프로토콜 : TCP, UDP
인터넷 프로토콜 스택의 4 계층
| 애플리케이션 계층 - HTTP, FTP | 웹 브라우저, 네트워크 게임, 채팅 프로그램 (등) (SOCKET 라이브러리) |
|
| 전송 계층 - TCP, UDP | OS | |
| 인터넷 계층 - IP | ||
| 네트워크 인터페이스 계층 | LAN 드라이버, LAN 장비 |
패킷이 생성되는 과정
1. 프로그램(웹 브라우저, 채팅 프로그램) 이 사용자가 입력한 데이터를 SOCKET 라이브러리를 통해 전달 (전송 데이터)
2. TCP 세그먼트 생성해 1번에서 생성한 데이터에 포함 (TCP 세그먼트)
3. IP 패킷 생성해 2번에서 생성한 데이터에 포함 (IP 패킷)
4. LAN 카드, 인터넷을 통해 서버로 전송! (이때 Ethernet Frame 이 씌워서 보냄)
IP 위에 무언가 얹어서 TCP!
TCP (전송 제어 프로토콜) : Transmission Control Protocol
1. 연결지향 - 먼저 연결을 하고 메시지를 보냄 (비연결성 해결)
2. 데이터 전달 보증 (비신뢰성 해결)
3. 순서보장 (동시성 해결)
TCP 세그먼트 : 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보.. 등이 포함
1. 연결 지황 - 3 way handshake
클라이언트와 서버 서로 SYN, ACK를 보냄
1. 클라이언트에서 서버로 SYN
2. 서버에서 클라이언트로 SYN + ACK
3. 클라이언트에서 서버로 ACK *ACK와 함께 데이터 전송 가능
--> 이 것은 개념적으로 연결된 것이다. (물리적이 아니다?)
2. 데이터 전송 보증
클라이언트에서 데이터 전송 후 서버에서 잘 받았다는 응답을 보냄
3. 순서 보장
패킷에 순서가 적혀? 있어서 순서가 바뀌어서 오면 틀린 순서부터 다시 보내달라고 서버에서 요청함.
TCP 세그먼트 안에 전송 제어, 순서 정보가 있어 가능!
UDP (사용자 데이터그램 프로토콜) : User Datagram Protocol
기능이 거의 없어 하얀 도화지..
IP와 거의 같고, PORT + 체크섬 정도만 추가 --> 어플리케이션에서 추가 작업 필요
TCP는 기능이 많아 무거움...
UDP는 기능이 가벼워 단순하고 빠름. 단, 데이터 전달 및 순서가 보장되지 않는다.
UDP를 사용할 때, 애플리케이션에서 정보를 추가할 수 있음!
PORT : 하나의 IP에서 여러 애플리케이션이 실행될 때 각 패킷을 애플리케이션과 매칭하기 위해 필요함
같은 IP 내에서 프로세스 구분!
IP : 아파트, PORT : 아파트 안의 동호수라고 비유하면 편하게 이해됨.
PORT번호
0 ~ 65525까지 할당 가능
0 ~ 1023: 잘 알려진 포트여서 사용하지 않는 게 좋음. (HTTP: 80, HTTPS: 443)
DNS : Domain Name System
DNS 서버에서 도메인과 IP를 매칭!
google.com --> 200.200.200.2
HTTP: Hyper Text Transfer Protocol
HTTP특징
1. 클라이언트 서버 구조 : 클라이언스틑 요청, 서버는 응답
2. 무상태 프로토콜 (Stateless) : 서버가 클라이언트의 상태를 보존하지 않는다! 이에 따라 클라이언트가 추가 데이터 전송
3. 비 연결성 (Connectionless) : 연결을 지속하지 않고, 응답 완료 후 연결이 끊어짐
4. HTTP 메세지
5. 단순함, 확장 가능
HTTP 지속 연결(Presistent Connections)
비 연결성의 문제점으로, HTML 파일 응답 후 JS 파일, 이미지 파일 등 여러 파일들을 추가로 보낼 때마다 3-way hand shake 발생
필요한 모든 파일을 응답으로 보내줄 때까지는 연결을 지속한다!
HTTP를 통해 보낼 수 있는 데이터
HTML, TEXT, Image, 음성, 영상, 파일, JSON, XML 등 거의 모든 형태의 데이터 전송 가능
서버 간 데이터를 주고받을 때도 대부분 HTTP 사용
URI : Uniform Resource Identifier
URI는 로케이터 이름 또는 둘 다 추가로 분류될 수 있다. 즉 URI는 URL, URN을 둘 다 포함
리소스를 식별한다? 주민등록증을 식별한다.
URL : 리소스가 이 위치에 있어요! (Locator)
URN : 리소스의 이름! (Name)
Uniform : 리소스를 식별하는 통일된 방식
Resource : URI로 식별할 수 있는 모든 것
Identifier : 다른 항목과 구분하는데 필요한 정보
URL 구조
scheme:// [userinfo@] host [:port] [/path] [?query] [#fragment]
https:// (생략) www.google.com :443 /search ?q=hello&hl=ko
schem : 주로 프로토콜 사용 (http, ftp 등등)
userinfo@ : 거의 안 씀, URL에 사용자정보를 포함해서 인증
host: 도메인명 또는 IP 주소를 직접 사용 가능
port : http : 80, https: 443 사용하므로 생략 가능
path : 리소스 경로, 계층적 구조
query : key = value 형태, ?로 시작, &로 추가 가능
fragment : html 내부 북마크 등에 사용. 서버에 전송하는 정보 아님.
'코딩 > 네트워크' 카테고리의 다른 글
| [HTTP] HTTP 헤더 (0) | 2023.05.28 |
|---|---|
| [HTTP] 쿠키 & 캐시 (0) | 2023.05.27 |
| [HTTP] 상태 코드 (0) | 2023.05.26 |
| [HTTP] 클라이언트에서 서버로 데이터 전송하기 (0) | 2023.05.25 |
| [HTTP] HTTP 메세지 & API URI 설계 방법 (0) | 2023.05.24 |