위 강의를 통해 공부한 내용을 정리함
인터넷 통신
클라이언트와 서버는 통신을 할 때 1:1로 연결되어 있는 것이 아니다.
중간에 인터넷이라는 여러 노드들을 거치게 된다
클라이언트와 서버 주소 위치 정보 (= IP) 가지고 통신은 할 수 있는데..
- 패킷 손실
- 노드 중 하나에서 송/수신 실패
- 서버에서 송/수신 실패
- 패킷 순서
- 송신 패킷 순서와 수신 패킷 순서가 다를 수 있음
위와 같은 문제가 있을 수 있음
말그대로 통신은 되는데 통신이 제대로 이루어짐을 보장할 수가 없음 ..
그래서 나온게 TCP / UDP 프로토콜 (전송 계층)
TCP / UDP
패킷에 IP정보만 명시하는 게 아니라 PORT, 전송 제어, 순서 , 검증 정보 등의 통신을 위한 다른 정보들을 명시한다.
→ TCP/UDP 프로토콜
- TCP 프로토콜의 특징
연결 지향 (3way handshake) 논리적 연결
데이터 전달 보증
순서 보증
- UDP 프로토콜
TCP 프로토콜이라는 제약이 강한 규약을 하나 만들어 놨음. (이건 이제 변경 불가능)
근데 TCP는 신뢰할 수 있는 프로토콜인 만큼 시간이 오래 걸릴 수 있음.
그래서 UDP를 만들어서 최적화의 여지를 남겨둠.
최소한의 조건 (PORT, 체크섬)만 남겨두고 나머지들은 필요한 경우 추가해서 사용하면 됨.
TCP 기능 거의 적용 안됨. (연결 지향, 전달 보장, 순서 보장)
TCP만 쓰다가 요샌 UDP도 쓰는 추세
PORT
서버 하나에서 여러 연결이 있을 수 있음.
이런 동시에 발생하는 연결들을 구분하는게 PORT
서버를 찾는 것 : IP ▷ 아파트
해당 서버에서 돌아가는 애플리케이션을 찾는 것 : PORT ▷ 동/호수
DNS
IP로 서버를 구분하는데 IP만으로 구분하는 것은 문제가 있음
- IP는 외우기 어려움 (xxx.xxx.xxx.xxx:port 이거 사이트마다 외울 순 없음)
- IP가 변경될 수 있음 (겨우 xxx.xxx.xxx.xxx:port 외웠는데 변경되면.. ?)
∴ DNS 서버를 하나 두고 IP 주소를 알기 쉬운 주소와 매핑해서 사용
URL ?? URI ?? URN ??
리소스가 있는 위치를 지정
어떤 프로토콜로
어떤 호스트(IP), 포트에
어떤 경로로
어떤 파라미터를
보내는지 정의해서 리소스를 요청할 수 있는 식별자 역할을 한다.
웹 브라우저의 요청 흐름
- 애플리케이션 계층에서 웹 브라우저가 URL 정보를 가지고 HTTP 메세지를 생성한다.
- 애플리케이션 계층에서 OS 계층으로 socket 라이브러리를 통해 전달
- OS 계층(TCP/UDP/IP) 에서 TCP, UDP, IP 패킷 달고 네트워크 인터페이스 계층으로 전달
'공부 > HTTP' 카테고리의 다른 글
HTTP ⁉ HTTPS ‼ HTTPS 개념과 NGINX, SPRING BOOT 어플리케이션 적용하기 (1) | 2022.02.22 |
---|---|
HTTP 웹 기본 지식 ➄ HTTP 헤더 / 캐시, 검증, 조건부 요청 (0) | 2022.01.02 |
HTTP 웹 기본 지식 ➃ HTTP 헤더 / 표현, 협상, 일반 정보, 인증, 쿠키 (0) | 2022.01.02 |
HTTP 웹 기본 지식 ③ HTTP 메세지 & HTTP 메소드 (0) | 2021.12.11 |
HTTP 웹 기본 지식 ➁ HTTP 특징 (0) | 2021.12.11 |