1. 인터넷 통신
단순 클라이언트와 서버의 연결이라면 케이블로 연결이 가능
멀어지면 인터넷 망을 사용해야하는데
어떠한 규칙(IP)으로 연결이 된다.
IP(인터넷 프로토콜)
클라이언트와 서버의 IP 주소가 각각 필요
지정한 IP 주소에 패킷 단위로 데이터를 전달
IP 패킷 정보
출발지 IP, 도착지 IP, 기타
클라이언트에서 서버로 패킷을 전달하면 전달이 성공했다는 패킷을 서버에서 클라이언트로 보내준다.
IP 프로토콜의 한계
-
비연결성
패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송 -
비신뢰성
중간에 사라지거나 여러개 보냈는데 순서대로 안오는 경우 -
프로그램 구분
같은 ip 사용하는 서버에서 통신하는 애플리케이션이 두 개 이상인 경우
TCP UDP
전송 내용을 TCP로 포장 -> IP 포장 후 전송한다.
TCP 정보
출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등
TCP 특징
-
연결지향(TCP 3 way handshake 가상 연결)
양방향 연결되어있을 때 보냄
-
데이터 전달 보증
-
순서 보장
잘못되면 잘못된 순서부터 재전송
UDP 특징
- 하얀 도화지에 비유(기능이 거의 없음)
- 연결지향 X (TCP 3 way handshake X)
- 데이터 전달 보증 X
- 순서 보장 X
- 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
- IP와 거의 같다. +PORT +체크섬 정도만 추가
- 애플리케이션에서 추가 작업 필요
PORT
TCP 정보에 포함되어있는 PORT는 같은 IP 내에서 프로세스를 구분하게 해준다.
-
0 ~ 65535 할당 가능
-
0 ~ 1023: 잘 알려진 포트, 사용하지 않는 것이 좋음
- FTP - 20, 21
TELNET - 23
HTTP - 80
HTTPS - 443
- FTP - 20, 21
DNS
IP는 기억하기 힘들고 변경될 수 있기 때문에 DNS를 사용
도메인 명을 IP 주소로 변환한다.
도메인 명을 사용해 DNS 서버에서 IP 주소를 찾고 접속할 수 있음
서버를 수평적으로 확장 할 수 있다.
2. URI
URI(Uniform Resource Identifier)
URI 는 URL 과 URN 을 포함하지만
URN 이름만으로 실제 리소스를 찾는 방법이 보편화되지 않아서
URL과 같은 의미로 쓰임
URI 전체 문법
scheme://[userinfo@]host[:port][/path][?query][#fragment]
https://www.google.com:443/search?q=hello&hl=ko
- 프로토콜(https)
- 어떤 방식으로 자원에 접근하는지에 대한 규칙
- userinfo
- 거의 사용하지 않음
- 호스트명(www.google.com)
- 포트 번호(443)
- 생략 가능
- 패스(/search) 리
- 소스 경로
- 쿼리 파라미터(q=hello&hl=ko)
- key=value 형태
- fragment html
- 내부 북마크에 사용
- 서버에 전송하지 않는다.
웹 브라우저 요청 흐름
-
호스트명을 DNS 조회하여 IP 주소로 HTTP 요청 메세지를 생성
- ex)
- ex)
- HTTP 메세지 전송
- 서버로 요청 패킷 도착
- 서버에서 HTTP 응답 메세지 전송
- ex)
- ex)
- 응답 패킷 도착 후 웹 브라우저 HTML 렌더링
3. HTTP
HTTP
- HTML, TEXT
- IMAGE, 음성, 영상, 파일
- JSON, XML (API)
- 거의 모든 형태의 데이터 전송 가능
- 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
HTTP 역사
- HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X
- HTTP/1.0 1996년: 메서드, 헤더 추가
- HTTP/1.1 1997년: 가장 많이 사용
- HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선
기반 프로토콜
- TCP: HTTP/1.1, HTTP/2
- UDP: HTTP/3
현재 HTTP/1.1 주로 사용
HTTP/2, HTTP/3 도 점점 증가
HTTP 특징
- 클라이언트 서버 구조
- 클라이언트와 서버를 분리해서 성능 개선
- Request Response 구조
- 클라이언트 : 요청, 응답 대기
- 서버 : 요청 결과 응답
- 무상태 프로토콜(스테이스리스)
- 서버가 클라이언트의 상태를 보존하지 않는다
- 클라이언트가 필요한 정보를 제공하여 서버가 바뀌어도 적용 가능
- 장점 : 서버 확장성
- 단점 : 클라이언트가 추가 데이터를 전송
- 모든 것을 무상태로 설계할 수는 없음 (로그인)
- 일반적으로 쿠키와 세션을 이용해 상태 유지
- 상태 유지는 최소한만 사용한다.
- 비연결성
- 클라이언트와 서버의 연결을 유지하지 않고 응답 후 끊음
- 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 매우 적게 된다
- 서버 자원을 효율적으로 사용 가능
- 한계
- TCP/IP 연결을 새로 맺어야 한다
- 웹 브라우저로 사이트 요청 시 수 많은 자원이 함께 다운로드 됨
- 모든 요청이 응답될 때 까지 연결하는 HTTP 지속 연결로 해결 되었다
- HTTP 메시지
-
HTTP 구조
-
시작라인 :
- 요청 메세지
HTTP 메서드 요청 대상 HTTP ver
- 응답 메세지
HTTP 버전 HTTP 상태 코드 -
헤더라인 : header-field = field-name ":" OWS field-value OWS
(용도 - HTTP 전송에 필요한 부가 정보) -
바디라인 : 실제 전송할 데이터
- 단순함, 확장 가능
Reference
유익해요