[Network] 네트워크 공부내용 정리

참고

• 책
  • 그림으로 배우는 http & network
  • http 완벽가이드
    
    
• 참고 사이트
  • 그림으로 배우는 http & network 정리글
  • http 완벽가이드 읽는법
  • zerocho 님 블로그 시리즈
  • wiki 백과(URI, URL, UDP)
    
    

글 작성 로그 및 수정 계획

• 2019.04.06 그림으로 배우는 http & network 정리글 블로그를 읽고 정리한 글
  • 실제 책(그림으로 배우는 http & network) 읽고 한번 더 정리
    • ch2 -> 트랜잭션 생성에 따른 통신 과정 - 2019.04.15
    • ch3 -> 데이터 타입에 따른
  • http 완벽 가이드 다시 읽고 정리 <- http 완벽가이드 읽는법
  • CORS, CORB 에러 정리
  • 쿠키 / 캐시 정리
    
    

TCP/IP

인터넷과 관련된 프로토콜을 모아놓은 것

대부분, IP프로토콜을 사용한 통신에서 사용되고 있는 프로토콜을 총칭해서 TCP/IP라고 함.
설계를 편하게 하고 유지보수를 위해서 계층화가 되어있음.

• 4계층
  • 애플리케이션 계층 - 유저에서 제공되는 에플리케이션 (FTP, DNS, HTTP)
  • 트랜스포트 계층 - 에플리케이션 계층에 네트워크로 접속되어 있는 컴퓨터사이의 데이터흐름을 제공(TCP, UDP)
  • 네트워크 계층 - 네트워크 상에서 패킷의 이동을 다룸. 여러대의 컴퓨터랑 네트워크 기기사이에서 길을 찾는 것(IP)
    • 패킷 : 전송하는 데이터의 최소 단위
  • 링크 계층 - 네트워크의 하드웨어적인 면 (케이블 등등)
    
    HTTP 데이터 -> TCP 헤더 -> IP 헤더 -> Eternet 헤더

IP

• 배송을 담당. 개개의 패킷을 상대방에게 전달. IP주소와 MAC(변경 불가)주소를 통해서 통신
• 어느 누구도 길에대한 정확한 위치를 알고 있지 않음(물어물어 찾아감)
• 네트워크에 존재하는 각 컴퓨터를 식별하기 위해 각각에 서로 다른 값을 할당한 것. 각 기기에 할당되는 것이 아니라 기기에 장착된 각각의 네트워크용 하드웨어에 할당 됨. 즉, 복수의 네트워크하드웨어를 장착한 기기는 복수의 주소 할당.
• MAC(Media Access Control Address) 주소 : IEEE에서 표준화된 LAN 방식의 기기는 모두 같은 형식의 주소를 사용하는데 이 주소를 가르킴. MAC주소를 사용하여 목적지를 찾아갈때는 ARP라는 프로토콜이 사용됨
• IP주소는 변경가능하나, MAC주소는 변경불가. ```shell $ ipconfig

이더넷 어댑터 이더넷:

연결별 DNS 접미사. . . . : 링크-로컬 IPv6 주소 . . . . : fe80::c160:8c0f:cef4:7ce8%13 IPv4 주소 . . . . . . . . . : 192.168.1.1 서브넷 마스크 . . . . . . . : 255.255.248.0 기본 게이트웨이 . . . . . . : 192.168.0.1

위의 IPv4주소가 내 컴퓨터의 IP주소. 192.168.1까지가 네트워크 주소, 맨뒤의 1이 호스트 주소.

네트워크 주소란?
: 공통적인 부분(중복이 되는 부분)

호스트 주소란?
: 식별할 수 있는 부분(중복이 없고 유일무이한)

예시 : 경기도 용인시 수지구 죽전동 A아파트 101동 1301호 네트워크 주소 : 경기도 용인시 수지구 죽전동 A아파트 101동 호스트 주소 : 1301호

IP는 32자리 2진수로 표현.

예시 172.16.254.1 | 172. | 16. | 254. | 1 | |—-|—-|—-|—-| | 10101100. | 00010000. | 11111110. | 00000001 |

## TCP(Transfer Control Protocol)

* 신뢰성을 담당
  * 바이트 스트림 서비스  
\: 큰 데이터를 보내기위에 TCP세그먼트라고 불리우는 단위 패킷으로 작개 분해하여 관리하는것. 대용량의 데이터를 보내기 쉽게 작게 분해하여 상대에게 보내고, 정확하게 도착했는지 확인하는 역할.
  * TCP Three way hand shaking (STN/ACK 플래그 사용)  
\: SYN으로 보내면 SYN/ACK 플래그로 패킷 수신한 사실을 전하면 ACK 플래그를 다시 보내 완료되었음을 전송. 도중에 끊키면 다시 반복

![TCP Three way hand shaking (STN/ACK 플래그 사용)](/assets/images/3way_hand_shake.png)  

## DNS(Domain Name System)

: 도메인을 주면 IP주소를 반환해줌 

## HTTP

* 클라이언트(웹브라우저)에서 서버까지 일련의 흐름을 결정하는 프로토콜
* HTTP자체는 잘 변하지 않음. 현재는 1997년 공개된 HTTP/1.1을 대부분 쓰고있음. 2.0이 탄생되었지만 표준화까지 시간이 오래걸림

> [HTTP 세션에 대한 설명](https://tobewiseys.tistory.com/72)
> [쿠키와 세션](https://sdevstudy.tistory.com/27)

## URI, URL

URI(Uniform Resource Identifiers)  
스키마를 나타내는 리소스를 식별하기 위한 식별자.  
스키마: 리소스를 얻기위한 수단에 이름을 붙이는 방법. (http, ftp, mailto, file, telnet 등).   


* Uniform
    * 통일된(Uniformity) 서식을 결정하는 것. 여러가지 종류의 리소스 지정을 구별없이 같은 맥락에서 사용할 수 있게 한다. (응??) 또한, 새로운 스키마(http:와 ftp등) 도입을 용이하게 함
* Resource
    * 식별가능한 모든 것. (도큐먼트 파일, 이미지, 서비스(ex. 오늘의 일기예보) 등 다른 것과 구별할 수 있는 것은 모두 리소스) 단일한 부분만 아니라 복수의 집합도 리소스임
* Identifier
    * 식별자. 식별 가능한 것을 참조하는 오브젝트. 

URI는 리소스를 식별하기 위해 문자열 전반을 나타내는데 비해

URL은 리소스의 장소(네트워크상의 위치)를 나타낸다.

URL은 URI의 서브셋이다. (URI = URL + URN)

<br><br>
URL 포맷<br><br>
![URL_syntax](/assets/images/URL_syntax.png)
<br><br>
URL 설명<br><br>
![URL_explain](/assets/images/URL_explain.png)
<br><br>
예시

http://user:pass@www.aaa.com:80/dir/index.html?uid=12#head1

<br>
예시 풀이

http:// user:pass @www.aaa.com :80 /dir/index.html ?uid=12 #head1 스키마(http), 자격정보, 서버주소, 서버포트, 계층적파일경로, 쿼리문자열, 프래그먼트식별자(#head1) ```

• 스키마
  • 리소스를 얻기위해 사용하는 프로토콜을 지시.
  • 대소문자 무시, 마지막에 콜론(:)이 붙음.
  • “data:”, “javascript:”같이 데이터와 프로그램도 지정 가능.
• 자격정보(=크리덴셜)
  • 서버로부터 리소스를 취득하려면 자격정보가 필요.
  • 유저명과 패스워드 지정. 이것은 옵션.
• 서버주소 : DNS이름(www.aaa.com)이나, IPv4주소(192.168.1.1)나, IPv6주소([0:0:0:0:0:0:0:1])를 쓸 수 있음.
• 서버포트 : 서버의 접속대상이 되는 네트워크 포트 번호 지정. 이것도 옵션. 생략시 디폴트 포트가 사용
• 계층적 파일경로 : 특정 리소스를 식별하기 위해 서버상의 파일 패스를 지정.
• 쿼리문자열 : 파일 패스로 지정된 리소스에 임의의 파라미터를 넘겨주기 위해 쿼리문자열을 사용. 옵션값
• 프래그먼트 식별자 : 취득한 리소스에서 서브리소스 (도큐먼트 중간에 위치)를 가리키기 위해서 사용. 옵션값

UDP와 TCP 비교[편집]

TCP는 데이터를 주고 받을 양단 간에 먼저 연결을 설정하고 설정된 연결을 통해 양방향으로 데이터를 전송하지만, UDP는 연결을 설정하지 않고 수신자가 데이터를 받을 준비를 확인하는 단계를 거치지 않고 단방향으로 정보를 전송한다.

• 신뢰성 - TCP는 메시지 수신을 확인하지만 UDP는 수신자가 메시지를 수신했는지 확인할 수 없다.
• 순서 정렬 - TCP에서는 메시지가 보내진 순서를 보장하기 위해 재조립하지만 UDP는 메시지 도착 순서를 예측할 수 없다.
• 부하 - TCP보다 속도가 일반적으로 빠르고 오버헤드가 적다.
  
  

간단한 프로토콜 HTTP

하나의 트랜젝션

TCP커넥션 연결 (쓰리웨이 핸드쉐이킹)

HTTP요청
HTTP응답

TCP커넥션 종료

• HTTP는 스테이트리스(Stateless)프로토콜이다. 과거에 교환했던 리퀘스트와 리스폰스의 상태를 관리하지 않음.
  이점도 있지만 이로인한 문제를 해결하기 위한 시스템 : 쿠키

쿠키 - HTTP 프로토콜의 스테이트리스 단점을 보완.

클라이언트 상태 파악하기 위함.
서버에서 리스폰스로 보내진 Set-Cookie라는 헤더필드에 의해 쿠키를 클라이언트에 보존.
다음번에 클라이언트가 같은 서버로 리퀘스트를 보낼 때, 자동으로 쿠키값을 넣어서 송신.
서버는 클라이언트가 보내온 쿠키를 확인해서 어느 클라이언트가 접속했는지 체크하고 서버상의 기록을 확인해서 이전 상태를 알 수 있음.

HTTP 매서드

• GET : 리소스 획득
• POST : 엔티티 전송.
• PUT : 파일전송. FTP에 의한 파일전송과 같이 리퀘스트 중에 포함된 엔티티를 리퀘스트 URI로 지정한 곳에 보존하다록 요구. 인증기능이 없어서 REST를 사용하는 경우에 사용. entity의 전체(ex - 모든 fields)를 바꿈(update)
• PATCH : entity의 일부만 바꿈(ex - 일부 fields)를 바꿈.
  • 참고(스프링에서의 정의) PUT replaces an existing entity. If only a subset of data elements are provided, the rest will be replaced with empty or null.
• DELETE : 파일 삭제. PUT매서드와 반대. 인증기능이 없어서 REST를 사용하는 경우에 사용.
• HEAD : GET과 같은 기능이지만 메시지 바디는 반환 안함. URI 유효성과 리소스 갱신 시간을 확인하는 목적으로 사용.
• OPTIONS : 제공하고 있는 메소드의 문의. 리퀘스트 URI로 지정한 리소스가 제공하고 있는 메소드를 조사하는데 사용함.
• TRACE : 경로조사. 프록시등을 중계할떄 추적위해 사용. 크로스 사이트 트레이싱(XST) 같은 공격을 일으킬 수 있으므로 거의 안쓰임. “Max-Forwards”라는 헤더 필드에 수치를 포함시켜 요청하면 서버를 통과할때마다 그 수치를 줄여나감. 수치가 0이 된 곳을 끝으로 200 OK 리스폰스 보냄.
• CONNECT : 프록시에 터널링 요구. TCP 통신을 터널링 시키기 위해서 사용함. 주로 SSL, TLS등의 프로토콜로 암호화된 것을 터널링 시키기 위해서 사용.

HTTP 상태 코드

참고 : 위키백과 HTTP 상태코드

• 1xx 정보
• 2xx 성공(Success)
• 3xx 리다이렉트(Redirection)
• 4xx 클라이언트 에러(Client Error)
  • 401(권한 없음): 이 요청은 인증이 필요하다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다. 상태 코드 이름이 권한 없음(Unauthorized)으로 되어 있지만 실제 뜻은 인증 안됨(Unauthenticated)에 더 가깝다. ex) CORS에러
  • 403(Forbidden, 금지됨): 서버가 요청을 거부하고 있다. 예를 들자면, 사용자가 리소스에 대한 필요 권한을 갖고 있지 않다. (401은 인증 실패, 403은 인가 실패라고 볼 수 있음)
  • 404(Not Found, 찾을 수 없음): 서버가 요청한 페이지(Resource)를 찾을 수 없다. 예를 들어 서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다.
• 5xx 서버 에러(Server Error)
  • 500(내부 서버 오류): 서버에 오류가 발생하여 요청을 수행할 수 없다.
  • 501(구현되지 않음): 서버에 요청을 수행할 수 있는 기능이 없다. 예를 들어 서버가 요청 메소드를 인식하지 못할 때 이 코드를 표시한다.
  • 502(Bad Gateway, 불량 게이트웨이): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 잘못된 응답을 받았다.

웹의 여러 애플리케이션

프록시 : 클라이언트와 서버사이에 위치한 HTTP 중개자

서버와 클라이언트 사이에서 중계 프로그램. 웹 보안, 어플리케이션 통합, 성능 최적화에 쓰임.
모든 웹 트래픽 흐름속에서 신뢰할 만한 중개자 역할을 한다.
요청과 응답을 필터링한다.
무언가를 다운받을 때 애플리케이션 바이러스를 검출하거나, 초등학교 학생들에게서 성인 콘텐츠를 차단한다.

캐시 : 많이 찾는 웹페이지를 클라이언트 가까이에 보관하는 HTTP 창고

프록시서버와 클라이언트 로컬디스크에 보관된 리소스 사본.
자주 찾는 것의 사본을 저장해두는 특별한 종류의 http프락시 서버다.
리소스를 가진 서버에 엑세스를 줄이는 것이 가능하기 때문에 통신량과 통신시간을 절약할 수 있다.

게이트웨이 : 다른 애플리케이션과 연결된 특별한 웹서버

다른 서버들의 중개자. 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용.
게이트웨이는 언제나 스스로가 리소스를 갖고있는 진짜 서버인 것처럼 요청을 다룸.
클라이언트는 자신이 게이트웨이와 통신하는 것을 알지못함.
예를들어 HTTP/FTP 게이트웨이는 GTP URI에 대한 HTTP요청을 받아들인 뒤, FTP 프로토콜을 이용해 문서를 가져옴. 받아온 문서는 HTTP메시지에 담겨 클라이언트에게 보냄.

터널 : 단순히 HTTP 통신을 전달하기만 하는 특별한 프락시

에이전트 : 자동화된 HTTP 요청을 만드는 준지능적 웹클라이언트

• 2023 1
• 2022 2
• 2019 45
• 2018 1