[TIL]0205_ http, network 공부 정리

Violet Lee·2021년 2월 5일
0

server

목록 보기
2/4

HTTP(hypertext transfer protocol)
:서버와 클라이언트가 주로 html문서를 주고받는데에 사용하는 프로토콜.
:서버와 클라이언트의 통신을 위한 규약.

  • UNIX의 기본 프로토콜로 사용되었고, 현재는 인터넷 범용 프로토콜로 사용되고있다..

  • 주로 tcp/udp 80번 포트를 사용.
    ex) https://www.codestates.com:8080
    👆(포트번호는 생략될수있기에, 주소창에서는 안보일수있다.)

    SEE ALSO : "tcp, udp, well-known port"
    MUST READ : "RFC 2616 - HypetText Transfer Protocol -- HTTP/1.1"

  • http/1.1의 경우 요청,응답은 start/status line, header 그리고 body로 이뤄짐.

    MUST READ : "https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages"

///////////////////////////////////////////////////////////

  • 속성
    1). stateless(무상태)
    : 앞의 요청에 대한 컨텍스트를 안가지기때문에 뒤의 요청을 별개로 생각해서 응답을 언디파인드하게 보냄.

2). connectionless(비연결성)
: 한번의요청엔 한번의응답을! 응답이후에는 연결끊김.
http의 각 요청은 모두 '독립'적이다.

///////////////////////////////////////////////////////////

🤔AN EXAMPLES OF THE HTTP REQUEST/RESPONSE MESSAGE

👉HTTP REQUEST
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
ex)
요청 uri 프로토콜/버전
GET /docs/index.html(요청한 html데이터) HTTP/1.1 | HEADER(REQUEST LINE)

Host: www.codestates.com | OPTIONAL REQUEST HEADERS
Accept: image/gif, image/jpes, / |
Accept-Language: en-us |
Accept-Encoding: gzip, deflate |
User-Agent: Mozila/4.0 (Compatible; MSIE 6.0;..) |

--blank area--

request payload | BODY(OPTIONAL)
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

👉HTTP RESPONSE
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
ex)
프로토콜/버전 상태코드 상태응답
HTTP/1.1 200 ok (상태코드 & reason phrases) | HEADER(STATUS LINE)

Date: Sun, 18 Oct 2009 08:56:53 GMT | OPTIONAL RESPONSE HEADERS
Server: Apache/2.2.14 (Win32) |
Last-Modified: Sat .... |
Content-Length: 44 |
Content-Type: text/html |
.
.

--blank area--

did it!

| REQUESTED BODY(OPTIONAL) (=> 정상적으로 잘 응답된 html내용)

CORS(Cross-Origin resource sharing) > 블로그보고 다시 정리
: 도메인 또는 포트가 다른 서버의 자원을 요청하는 메커니즘.
다른출처에서들어오는요청을 막거나 풀어준다. 즉, 크로스오리진의 요청을 듣거나 막아줄수있다.
즉, 신뢰할 수 있는 클라이언트에만 응답하려고

*이때 요청을 할 때에는 cross-origin HTTP에 의해 요청된다.

심플 리퀘스트시 json을 주고받을때 허용여부를 응답으로 받음..
cors는 서버단에서 설정하는것임 < 0204_ 이를 내일(0205) 스프린트에 사용하므로 미리 알아봐야함.

프로토콜,도메인,포트 중에 하나라도 허용된것이 아니면 크로스오리진이라 할수없음.

*cross origin을 결정하는 기준은 프로토콜의 차이!!

ex) http://domain-a.com으로부터 전송되는 html페이지가,
src속성을 통해 XMLHttpRequest를 사용하여,
http://domain-a.com/image.jpg를 요청하는경우가 있다.

오늘날 많은 웹페이지들은, css 스타일시트,이미지 그리고 스크립트와 같은 리소스들을
각각의 출처로부터 읽어오며 이를 cross-origin request라고 한다.

하지만 동일 출처 정책(same-origin policy)때문에 cors같은 상황이발생시
외부서버에 요청한 데이터를 브라우저에서 보안목적으로 차단한다.

*동일출처정책: 불러온 문서나 스크립트가, 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 중요한 보안방식임. 이것은 잠재적 악성문서를 격리한다.

...그로인해 정상적으로 데이터를 받을수없게 된다.

XMLHttpRequest, fetch API는 이 동일출처정책을 따르며,
이 api들을 사용하는 웹애플리케이션은 자신의 출처와 동일한 리소스만 불러올수있으며,
다른 출처의 리소스들을 불러오려면
그 출처에서 올바른 cors헤더를 포함한 응답을 response해야한다.

즉 cors를 사용하는 요청은 XMLHttpRequest, fetch API만 가능하다.

EXAMPLES OF ACCESS CONTROL SCENARIOS

  • SIMPLE REQUEST

  1. 'GET','POST','HEAD'메소드 중 하나만을 사용하여 요청해야함.

  2. header에 별도의 속성 추가를 하면 안되고,
    mdn에 기술된 기본 header만 option으로 들어가야함.

    cors header를 사용하여 서버와 클라이언트간의 데이터교환을 나타낸것.
    ----------------------------------------------------------------

클라이언트 -----------------------------> 서버
(Simple request)
GET /doc HTTP/1.1
Origin: Server-b.com

	   <-----------------------------
		      HTTP/1.1 200 ok
Access-Control-Allow-Origin: *(실제론 * 쓰면 다 허용해버리니 안됨..)
		      
	  
            xhr.send()

js code ------------------> browser -------------------------------> server
preflight req(if nessasary)

						-------------------------------->
  • PREFLIGHT REQUEST

    서버의 요청수정을 위해서는 그 요청이 안전한지 확인하는것.

: 'PUT','DELETE','CONNECT','OPTIONS','TRACE','PATCH'메소드 중 하나만을 사용하여 요청.

  • 실질적인 요청 전에 option메소드를 통해
    먼저 메시지가 간것이, 네트워크탭에 보일것이다.
    이게 바로 프리플라이트 리퀘스트가 된것이다!!!!

    그럼으로, 실제 요청이 안전한지 서버가 미리 파악할수있도록 하는 수단이다.

  • 그리고 모든 cross origin요청이 이걸 발생시키는것이 아니다.

    심플 리퀘스트를 실행하지못하면 프리플라이트가 실행된다.
    즉, 심플 리퀘스트 실행 시, 프리플라이트를 실행하지 못한다.

mdn에 기술된 특정 세개의 header속성이 아닌 다른 속성을 만약에 상요한다면
이 프리플라이트 리퀘스트가 실행된다고 함.

----------------------------------------------------------------

클라이언트 -----------------------------> 서버
(Simple request)
GET /doc HTTP/1.1
Origin: Server-b.com

	   <-----------------------------
		      HTTP/1.1 200 ok
Access-Control-Allow-Origin: *

🤔만약 어떤 페이지의 url을 주소창에 쳐서 불러온다면..

코드스테이츠만 해도 개발자도구를 킨 상태로 '네트워크탭'을 보면 수많은 get요청된 자원들이
response로 잘 들어있는것을 볼수있다.
*참고로 어떤 페이지의 url을 주소창에 쳐서 불러오는 행위는 모두 get요청임

그 중, 제일 상단에 있는 최초로 http요청을 한 내역을 볼수있는데, 클릭해서 내용들을 확인해보면

💓 General(
ex) Request URL : https://codestates.com/ | Request Method: GET | status code: 304
| remote address : 13.35 .. | policy : no-referrer- ...)

과,

💓 request header(
ex) authority: codestates.com | method: GET | path: / | scheme : https
| accept : text/html, application/xhtml+xml, application/xml;q=0 ..
| Accept-Language: en-us | Accept-Encoding: gzip, deflate : Cookie: ass group id=...)

👆만약 정식으로 도메인을 사서 생성된 url이 아닌, '개발자 임의로 만든 url'이면,
저자, 메소드, 경로, 스킴 은 안나오고 GET url, host, connection 필드가 나오는듯...

👆 만약 페이로드를 주는 요청이라면 주소검색도 해당하는진 모르지만 채터박스의 경우
리퀘스트 페이로드에서 보낸 유저네임,텍스트,룸네임 확인도 가능하단 사실 ㅇㅇ

와,
잘 응답이 되었으므로

💓 response header(
ex) age: 76486 | date: Tue, 02 Oct 2018 GMT | server: AmazonS3 | status:304
| via: 1.1 blabla... )까지 확인해볼수있다.

👆만약 정식으로 도메인을 사서 생성된 url이 아닌, '개발자 임의로 만든 url'이면,
age, date, status, via는 안나오고, HTTP 1.1 304,accept-ranges:bytes, 캐쉬컨트롤?

이런게 나오는듯 ㅇㅇ

❗IF!!!! 잘못된 요청이 간다면 네트웤탭에서는??!!❗

만약 codestates.com/saffsfs 뭐 일케 이상한 라우팅을 시키면
하고 네트워크탭 들가보면 404 스테이터스 요청 내역이 생긴게 보일거임 ㅇㅇ

400번대 에러: 클라이언트 에러.
👆 참고:우리는 공부중에 아마 400 bad request(= 잘못된 요청)에러를 현재 많이 볼수있을거라 함!!
500번대 에러: 서버 에러 -> 서버 터진거임
//////////////////////////////////////////////////////////////////////////
👆참고: 네트워크탭의 전송내역은, 웹서버에서 클라이언트가 제공될때!! 사용이 가능하다 당연히.

     즉, file:// (x), http:// (o)  인 경우 http 패킷확인이 가능한것이다 언더스탠?

❓먼저 검색창에 url을 입력후 엔터를 치면? : 실제로는 많은일이 그안에서 벌어지고있다.❓

 프로토콜/       host           /        path

ex) http://www.google.com/int1/ko_kr/about/

//////////////////////////////////////////////////////////////////////////

STEP ONE: 도메인 이름 탐색

  1. dns서버에 접속한후, 프로토콜 뒤 www.google.com의 ip가 뭔지 요청.
  2. dns서버는 요청에대한 응답으로 216.58.197.196 리턴.

위의 www.google.com부분이 실제로 어떤 ip를 갖고있는지, dns서버(도메인서버)에 물어본다.
👆참고: 응답으로 온 global ip주소를 주소창에 그대로 치면, 그 사이트(ex) google)가 그대로 나옴.
😥 *if step 1 fails...
→ 만약 유효하지않은 ip주소라면 err_name_not_resolved 이런 에러뜨면서 안나올꺼임

//////////////////////////////////////////////////////////////////////////

STEP TWO: 웹 서버(http)요청

  1. 웹 서버의 라우팅(routing : 주소탐색규칙. 디테일한 주소.)에 따라 요청을 처리함.
  • 단순히 정적파일만 제공하는경우 다음과 같이 조회(url) 할수있다.
    ex) 웹서버루트/int1/ko_kr/about/index.html
  • 서버가 비즈니스 로직을 실행하도록 요청할수도 있다.
    ex) 웹서버루트/search?q=codestates
    웹서버루트/preferences
  1. 요청 후, 서버가 요청에 대한 응답을 자원(resource: HTML이면 html내용/아니면 JS파일등)의 형태로 전달한다.
    😥 *if step 2 fails...
    → 404 not found 라는 존재안한다는 에러뜰거임
  2. 서버가 보내주는 자원을 브라우저에서 처리

URI(uniform resource indentifier)
: 파일을 요청하는것 뿐만 아니라, 비즈니스로직 처리도 요즘은 해서, url을 이렇게? 요즘은 부른다.

  • http요청은 uri를 통해 할수있다.
    👆참고: 주소창을 통해 하는 요청은 전부 GET request

😋레퍼런스😋

👊❗❓ 네트워크 탭도 경로가 있음 ㄷㄷ

chrome devtool: network tab
-> https://developer.google.com/web/tools/chrome-devtools/network-performance/reference
(구글의 개발자도구-네트웤탭 경로)

👊

0205 socrative

  1. *Content-Type을 살피면 payload가 뭐가 들어오는지 알수있음.

*unexpected token h in json at position 0

json을 읽어오지 못할때, 즉 json을 파싱하지 못할때의 에러.

profile
Violet Lee
예비개발자
이전 포스트

[TIL]0204_interaction with server(부제: client)

다음 포스트

[TIL]0209_ Refactoring the chatterbox server with express.

0개의 댓글