https://kth990303.tistory.com/311로 이동해주세요!
단순히 요약본 txt를 그대로 포스팅에도 복붙한 것이다.
나중에 정리해서 요약할 예정이다.
복잡한 인터넷 망
클라이언트 -> 서버 로 메시지 전달
: 클라이언트, 서버의 각각 ip 주소 존재
: 패킷(Packet)이라는 통신 단위로 전달하고픈 ip 주소로 데이터 전달
클라이언트 패킷 전달할 때, 노드가 프로토콜 규약으로
출발지, 목적지, 메시지 등 파악 -> 노드끼리 패킷 전달 후 서버에 도달.
서버 패킷 전달할 때, 클라이언트 패킷 전달때와 방향만 반대, 내용 같음.
이 방식만으론 한계가 있음.
-비연결성
-비신뢰성
(대략 메시지가 1500바이트 이상이면 메시지를 끊어서 보낸다고 함.
따라서 메시지 순서가 섞여서 도달할 가능성 존재)
-프로그램 구분
-> TCP/UDP가 문제점 해결
TCP
인터넷 프로토콜 4계층
애플리케이션-socket 라이브러리(http, ftp)
OS - TCP/UDP, IP
네트워크 인터페이스-LAN 카드
클라이언트 -> 메시지
-> 소켓 라이브러리를 통해 os로 넘김
-> 메시지에 tcp 정보 생성
-> ip 패킷 생성
-> 네트워크 인터페이스에서 lan카드를 통해 나감. (이더넷 프레임까지)
TCP/IP 패킷정보
ip만으로 해결이 안됐던 문제들을 port, 전송제어, 순서 등의
tcp 정보들로 해결가능
-tcp 특징: 전송 제어 프로토콜
->연결지향 (연결 여부 확인)
:TCP 3 way handshake
:1. SYN(syncronized)(클라이언트의 서버측 접속요청)
2. SYN(서버의 클라이언트 측 접속요청)+ACK(요청 수락)
3. ACK(클라이언트 측 요청 수락, 요즘은 이 때 데이터 바로 전달하기도)
단, 중간 노드들 연결여부 확인 x
->데이터 전달보증
->순서 보장
: tcp 패킷 정보 덕분에 패킷순서 점검도 가능
현재는 대부분 tcp 사용
-udp 특징: 사용자 데이터그램 프로토콜
:ip와 거의 같으나, port, 체크섬 정도 추가
(port: 같은 ip에서 여러 프로그램 돌릴 때 여러 패킷: 여러 port)
: tcp보다 기능도 적고 별 것 없는데 쓰는 이유: 단순하고 빠름
: udp로 기능 일부 추가하면서 최적화하는 경우 존재 (최근 뜨는 중)
-Port
: 한 번에 둘 이상 연결해야 하는 경우
ip: 200.200.200.2 , port: 11220 <-> ip: 100.100.100.1 port: 8090
-> 0~65535: 할당 가능 / 0 ~ 1023: 잘 알려진 포트: 사용하지 않는 게 좋음
-DNS(Domain Name System: like 전화번호부)
: ip는 기억하기 어렵고, 변경될 수 있음.
'CS > Http, Network' 카테고리의 다른 글
[매트 스터디] 5주차 HTTP 헤더2 - 캐시와 조건부 요청 (0) | 2022.06.01 |
---|---|
[매트 스터디] 4주차 HTTP 헤더 1 - 일반 헤더 (0) | 2022.05.22 |
[매트 스터디] 3주차 HTTP 메서드 활용 & HTTP 상태코드 (2) | 2022.05.15 |
[매트 스터디] 2주차 HTTP 기본 & HTTP 메서드 (0) | 2022.05.09 |
[매트 스터디] 1주차 인터넷 네트워크 & URI와 웹 브라우저 요청 흐름 (2) | 2022.04.30 |