Http 통신을 따로 빼놓은 이유는, 노션에 설명하기엔 다소 해비한 감이 있어서 따로 빼놓았다.
이해할 당시에도 내 선에선 복잡하고 다소 어려운 부분이 있어서 이해하기에 약간의 시간이 걸렸던 기억이 있기에,,,ㅎ

그 전에, 7계층까지 모든 장비의 역할을 말해보겠다
(TOP-DOWN 기억)

단말

1. 7,6,5 계층 일: 메시지

2. 4,3,2 계층 일: 옷 갈아입히기

3. 1 계층 일: 시그널링

   L4 스위치

4. 4계층 일: PORT SWITCHING

5. 3,2 계층 일: 옷 갈아입히기

6. 1계층 일: 증폭

   라우터

7. 3계층 일: 라우팅(스위칭)

8. 2계층 일: 옷 갈아입히기

9. 1계층 일: 증폭

   스위치

10. 2계층 일: 스위칭&플러딩

11. 1계층 일: 증폭

    분업화: 전문화

    

HTML 문서 교환을 위한 request(요청)<-> reply(응답) 인 application 계층 프로토콜

Request 메시지: HTTP GET/POST/DELETE
Response 메시지: 2xx/3xx/4xx/5xx Message

★Request
GET: download
POST: upload
DELETE: 삭제

☆Response
200 OK
3XX (Client가 원하는)문서가 다른 곳으로 이동
4xx client error
5xx server error

옷: 주소, 타입과 순서 번호 등의 정보들
Capsulation: 옷 입히기

4계층까지 입음: Segment
3계층까지 입음: Packet
2계층까지 입음:Frame

수신 장치는 반대로 bottom-up 프로세스가 일어남

그런데, 각 계층 헤더에는 그 상위 프로토콜을 구분하는 숫자가 들어가기에 쉽게 말하면
타입, 프로토콜, 목적지 포트는 안에 뭐가 들어있는지 표시한다(위에 뭐가 들어있는지 표시한다) 라고 할 수 있다

그렇다면 동일한 두 장치 사이에 동일한 두 HTTP 커넥션 연결했을 때 이 커넥션들을 구분하는 방법은?

따로 없다 그저 출발지 포트를 확인해보면 알 것.그래서 SRC PORT가 없다면 두 커넥션을 구분할 수 없음,,

TCP vs UDP

TCP

데이터 덩어리 자름 => 헤더에 순서 번호 포함

UDP

데이터 덩어리 자르지 않음

자르는 것은 출발지에서, 조립은 목적지에서!

Unicast: 1대
Multicast: 특정 그룹
Broadcast: 모든 장치들

플래그를 통해 커넥션 오픈,유지 종결을 판단함

그래서 TCP의 커넥션 과정은?

사실 다른 포스팅에서도 했지만 한번에 보고 싶으므로 다시 정리를 하도록 하겠다 분명 효율성면에서 어긋나지만 전체 정리를 해보고 싶었기에..

그림은 예시고,

WIN 크기: 그 크기만큼 보내라는 것

1. 3 way handshake를 통해 커넥션 오픈 (syn->syn/ack-> ack)

• 이것도 예약 전화로 생각해보면 쉽다
  1-1.고객이 음식점에 전화해서 예약을 요청 ("00시에 예약하고 싶어요")-SYN
  1-2. 음식점에선 예약 가능 여부를 확인하고 고객에게 가능한지 응답함("예약 가능해요 몇 분이 오실건가요?")-SYN/ACK
  1-3. 예약이 확정됨 ("총 0명입니다 감사합니다")- ACK
  

2. 이렇게 커넥션이 열리고 연결이 설정된 후, 클라이언트와 서버는 데이터를 주고받음 (데이터 전송)
   #데이터 송신 - 데이터 수신 및 확인 응답(ACK)

• 이것도 비유를 보며 이해해보자
  2-1. 데이터 전송 시 송신자는 데이터를 여러 SEGMENT로 나눠 전송함(아까 쪼갤 수 있다 했지? 공유도 가능), 각 세그먼트는 순서번호와 응답 번호를 포함함
  => 쉽게 말해서, 아까 예약했으니까 음식점가서 실제로 음식을 주문하는 과정이라고 생각하면 됨
  -> 데이터 송신 = 음식 주문 (고객이 도착해서 음식을 주문함 -"저 00이랑 00주세요")
  2-2. 수신자는 데이터를 받으면, 그것을 확인하는 ack패킷을 송신자에게 보냄(ack패킷 = 수신된 데이터의 다음 순서 번호를 포함)
  => 손님이 아까 주문했으니 음식점은 주문을 받고 음식 준비 후 손님에게 제공("여기 주문하신 음식이 나왔습니다 00이랑 00맞나요?")
  2-3. 확인 응답 => 고객이 음식을 받고 확인("네 맞아용 감사해요")

3. 연결해제(4-way HandShake)
   #FIN - ACK -FIN -ACK

• 흠...비유를 해보자...
  3-1. 연결을 종료하려는(통상적으로는 클라이언트)측이 FIN 패킷 전송
  => 음식을 먹고 도망갈 수는 없으니까,, 고객이 식사를 마치고 계산을 요청함( "계산서 좀요,,")
  3-2. 반대 측(서버)은 FIN 패킷 수신 후 이를 확인하는 ACK 패킷 전송
  => 음식점이 계산서 제공& 확인("00이랑 00드신 것 맞으시죠? 여기 계산서요")
  3-3. 클라이언트만 종료할 수 없지 서버도 연결 종료하고자 할 때 FIN 패킷을 클라이언트에게 전송
  => 고객이 계산서를 받고 결제("결제완료했습니다")
  3-4. 클라이언트는 서버의 FIN 패킷 확인 후 이를 확인하는 ACK 패킷 전송
  => 음식점이 결제를 확인하고 거래를 종료("네 결제 되셨어요 안녕히 가세요!")

패킷 트랜잭션

자 이 그림으로 설명을 해보자 (여기서 IP 브로드캐스트 주소는 255.255.255.255고 MAC 브로드캐스트 주소는 FFFF.FFFF.FFFF.FFFF라고 해보자 ->ARP필요X)
일단 PC A에서 작동을 시작해야 한다
1-1. 통신을 하기 위해 DHCP서버를 먼저 찾아야 함 (IP주소나 DNS 서버 주소 등을 알아내야 하기 때문)-> 네트워크에 자신의 존재를 알리기 위해 브로드캐스트로 DISCOVER 메시지 보냄~~ DISCOVER
: 쉽게 말하면, 전학생이 학교에 처음 왔는데 이 학생은 선생님(DHCP 서버)을 찾기 위해 교실 전체(네트워크)에 "선생님 어디 계세요?"라고 크게 묻는 것과 같기 때문에 모든 학생(네트워크 장치)들도 이 소리를 들을 수 있음

1-2. DHCP 서버:"ㅇㅋ~받았어 나는 너에게 OFFER 메시지를 줄게" -> 클라이언트에게 사용가능한 IP 주소 및 서브넷 마스크 등을 제안함 OFFER
: 선생님이 그 학생의 호출을 듣고 "여기 있어 너에게 자리를 줄게 이건 너의 자리 위치(IP주소)야" 라고 대답함

1-3. 클라이언트가 제안된 IP 주소를 사용하기로 하고 REQUEST 메시지를 통해 이를 요청하는데 클라이언트는 해당 IP 주소가 이미 다른 장치에서 사용 중인지 확인해야 함 -> ARP요청 보냄 REQUEST
: 전학생이 선생님이 안내한 자리를 받고 "네 이 자리를 이용할게요 근데 혹시 이 자리에 앉아있는 다른 학생이 있나요?" 라고 교실 전체에 묻고 확인함

1-4. DHCP 서버가 클라이언트 요청 승인하고 최종적으로 IP 주소 할당하는 메시지 보냄 ACKNOWLEDGE
: 선생님께서 "응 그 자리에 앉아도 돼 이제 그 자린 네 겁니다" -> 전학생에게 그 자리가 할당되어 사용할 수 있게 됨

자 이제 PC A는 통신을 할 수 있다

PC A가 네이버 웹 서버에 접속한다고 가정해보자
네이버 웹 서버의 도메인 네임은 www.naver.com 만으로는 그에 해당하는 ip주소를 바로 알 수 없다 -> 이렇기에 DNS 서버가 필요한 것!

2-1.DNS 쿼리 시작

• 사용자가 URL을 웹 브라우저에 입력하면, 그 도메인 네임에 해당하는 IP 주소를 찾기 위해 DNS 쿼리 시작
  => 사용자가 특정 책의 제목을 알고 있으나 위치는 모를 때 그 위치에 대한 물음이 DNS 쿼리와 같음 2-2. 로컬 DNS 캐시 확인/ 로컬 DNS 서버에 쿼리 전송
  전자의 상황에선 이전에 조회한 결과가 있다면 바로 사용하지만 후자의 경우엔? -> DNS 서버에 쿼리 전송
  2-2-1. 일단, DNS 쿼리 패킷을 보내기 위해선 프레임의 목적지 MAC 주소를 알아야 함

  왜냐고? IP 가 3계층이라 그 이하인 2계층 주소도 알아야함(IP 주소는 3계층에서 사용되지만, 실제 데이터는 2계층의 MAC 주소를 통해 전송되기 때문)
  IP 주소는 네트워크를 통해 패킷을 전송하는 데 사용되는 논리적 주소고 MAC 주소는 LAN에서 데이터 프레임 전달하는 데 사용되기 때문,,

  -> DNS 쿼리 패킷은 라우터에 도착하면 다음 네트워크에서도 ARP 교환을 통해 2계층 옷으로 갈아입히기! -> 어찌 저찌 ARP 요청과 응답으로 MAC주소를 알아냄(다른 포스팅에 더 자세히 기재되어 있음)
  2-2-2. MAC 주소를 얻으면 DNS 쿼리 패킷을 2계층 데이터 프레임으로 캡슐화하고 로컬 DNS 서버에 전송 2-3. DNS 쿼리 수신 -> DNS 캐시 확인( 만약 캐시에 결과가 없다? 다른 DNS 서버에 쿼리 전달,,,) 2-4. 재귀적 쿼리 수행
  2-5. 권한있는 DNS 서버가 IP 주소 포함한 응답을 로컬 DNS서버에 전송->클라이언트에게 전달

  클라이언트는 이제 해당하는 도메인 네임의 IP 주소를 알아냈습니다!

  이것도 비유로 해볼까요?? 1. 고객: "저녁에 음식을 먹으러 갈 음식점 예약을 하자."
  음식점 이름 입력: "저는 '파스타 하우스'라는 음식점에 가고 싶어요."
  로컬 예약 확인 (로컬 DNS 캐시 확인)

2. 캐시 확인: 이미 '파스타 하우스'에 대한 예약 내역이 있으면, 그 예약을 바로 사용
   캐시 미스: 예약 내역이 없으면, 음식점에 직접 전화하여 예약을 확인해야 함(로컬 DNS 서버에 쿼리 전송)

   3. 전화번호 확인 (MAC 주소): 음식점에 전화를 걸기 위해,,
   전화 연결: 전화번호를 통해 전화선(로컬 네트워크)의 물리적 연결을 설정.
   전화 교환기 (ARP 프로세스): 전화선의 물리적 경로를 확인하여 연결을 설정
   음식점의 예약 확인 (로컬 DNS 서버의 처리)

   예약 확인-> 예약 정보 확인 -> 예약 확인 (재귀적 쿼리 수행)

   4. 지역 음식점 관리자: '파스타 하우스'가 어떤 지역 음식점 체인인지 확인
   체인 본사: 지역 체인 본사의 정보와 예약 시스템을 확인
   최종 확인: 본사에서 예약 정보를 확인하고 응답 보내줌
   예약 응답 (응답 반환)

   5. 예약 정보 제공: 음식점이 예약을 확인하고, 사용자에게 예약 정보를 전달
   정보 저장: 음식점이 예약 정보를 자신의 시스템에 저장하여 다음에 참조할 수 있도록 함
   식사 준비 (클라이언트의 DNS 응답 처리)
   

3. TCP 3-WAY HANDSHAKE

~~이에 대한 설명은 많이 했으므로 간단하게만 기재하겠다~~
 TCP는 DNS 서버에 의해 알아낸 IP 주소를 가진 목적지 장치와 TCP 3 WAY HANDSHAKE 수행
 -> 불필요한 데이터 전송 막을 수 O(통신의 성공 여부 미리 확인)
 

4. HTTP GET 과 200 OK

 1. HTTP Get: 다운로드할 파일 
 2. 200 OK: 성공(데이터)