오늘부터 밀린 TIL을 조금씩 완수해보려 한다.
하나가 덜 완성되더라도, 포기하지 말자.
BROWSER
: HTML과 CSS명세에 따라서, html파일을 '해석'하여 표시하는 역할.
최근에 사용하는 브라우저로는 IE, 파이어폭스, 사파리, 크롬, 오페라
이렇게 다섯개의 브라우저를 많이 사용하는데,
2012년 3월 현재 파이어폭스, 사파리, 크롬의 점유율은 높은 62.57%에 달한다고 한다.
오픈소스 브라우저가 시장의 상당부분을 차지하게 된 것이다.
과거에는, 브라우저들이 일부만 CSS명세에 따라 구현을 하게되고, 독자적인 방법으로 확장함으로써,
웹 제작자가 심각한 호환성 문제를 겪게 된일이 많았지만, 최근에는 대부분의 브라우저가 이 표준명세를 따른다.
참고로 이 CSS명세는 웹 표준화 기구인 W3C(World Wide Web Consortium)에서 정하는것이라고 한다.
👉 브라우저의 사용자 인터페이스의 요소들
- URI를 입력할 수 있는, 주소 표시줄
- 이전 버튼 / 다음 버튼
- BookMark
- 새로 고침 버튼 / 현재 문서의 로드를 중단할수있는, 정지버튼
- 홈 버튼
👉 브라우저의 기본 구조
1. 사용자 인터페이스
- 주소 표시줄, 이전/다음 버튼, 북마크 메뉴 등. '요청한 페이지를 보여주는 창을 제외한, 나머지 모든 부분을 가리킴.'2. 브라우저 엔진
- 사용자 인터페이스와 렌더링 엔진 사이의 동작제어.3. 렌더링 엔진
- 요청한 콘텐츠를 표시. 예를들어 html을 요청하면, html과 css를 파싱해서 화면에 표시해줌.4. 통신
- http요청과 같은 네트워크 호출에 사용됨. - 이것은 각 플랫폼 하부에서 실행된다.5. UI 백엔드
- 콤보박스와 창같은, 기본적인 장치를 그림. - 플랫폼에서 명시하지'않은' 일반적인 인터페이스로서, OS사용자 인터페이스 체계를 사용.6. 자바스크립트 해석기
- js코드를 해석하고, 실행7. 자료 저장소
- 이 부분은 자료를 저장하는 계층이다. - 쿠키를 저장하듯이, 모든종류의 자원을 하드디스크에 저장해야 한다. - html5 명세서에는 브라우저가 지원하는 웹 데이터베이스가 정의되어있다.
API
: 서버가 클라이언트의 요청을 받아서 리소스를 처리하여 다시 돌려주는 구조이다.
서버자원을 잘 쓸수 있게 만들어놓았다. > interface라고 보면됨.
예)
메뉴판(api)이 있어야, 서버는 원두(db)를 바탕으로 음료(리소스)를 만들어 제공할수있다.
서버는 그러므로 데이터요청을 위해, get/messages 메소드로 요청메시지를 전달한다.
그리고 post/massages 메소드로 메시지를 저장도 할수있다.
HTTP
- hypertext transfer protocol의 약자. > 통신규약을 뜻함. 서버와 클라이언트의 통신을 위한 규약이다.
- UNIX의 기본 프로토콜로 사용되었고, 현재는 인터넷 범용 프로토콜로 사용되고있다..
TCP/IP(transmission control protocol/internet protocol)
: 인터넷에 연결된 서로 다른기종의 컴퓨터들간에 데이터를 주고받을수 있도록 하는 표준 프로토콜.
*TCP/IP의 TCP는, OSI 7계층의 전송계층에 해당되는데,
이 중, 클라이언트가 OSI환경에 접근할수있도록 서비스를 제공해주는 응용계층을 http가 담당한다.
- 속성
1). stateless(무상태)
: 앞의 요청에 대한 컨텍스트를 안가지기때문에 뒤의 요청을 별개로 생각해서 응답을 언디파인드하게 보냄.2). connectionless(비연결성)
: 한번의요청엔 한번의응답을! 응답이후에는 연결끊김.
http의 각 요청은 모두 '독립'적이다.
- 작동방식
: 항상 요청/응답으로 이루어짐. 없으면 없다는 응답을 줌. ❗반드시 응답을 줘야함.
요청무시하면 오류발생함.
- 구성
(1). request객체의 구성
- 헤더(어디서 보내는 요청인가(origin)
- 컨텐츠타입은 뭔가(content-type)
- 어떤 클라이언트를 사용해 보냈는가(user-agent))
와 바디( 서버에 데이터를 보내기위한 공간으로 활용.)로 구성.
(2). response객체의 구성
: 헤더와 바디로 구성.
- http 메소드
1) 자주 사용하는 메소드
- get : 서버에 자원요청. 그러면 서버는 url이 지정한 자원을 찾아서 클라이언트에게 응답.
-조건부(conditional)GET: 서버에게 특정조건이 만족될경우, 자원을 보낼것을 요청함.
ex) 'if-Modified-Since','if-Match'같은 헤더를 사용하는경우!
-부분적(Patial)GET : 보통 큰 파일을 요청할때 자원의 일부분만을 요청하는 Range헤더를 사용할 경우!
- post : 서버에 자원 생성. 클라이언트가, 임의의데이터를 포함한 '실체'를 서버로 보낼수있게 하는 메소드이다.
- head : '실체'를 클라이어트 측에 보내지말라고 서버에게 요청할때 쓸수있음.
파일의 존재, 상태, 크기 점검을 위해 사용한다.
얘에 대한 응답은, get메소드 response객체의 '실체헤더를 제외한 헤더부분'이다.
--------------------------------------------------------------------------------------------------------------------------------
2) 기타 메소드
- put : 서버의 자원 수정(즉 덮어씌움).> 이말이 mdn의 '요청 페이로드로 바꾼다'는 말과 동일.
FTP protocol을 사용할때등등 자주 사용되는 메소드는 아니지만, 사용하게된다면 반드시 인증과정이 필요하다!
- delete : 서버의 특정자원 제거.
- options : 클라이언트가 이용가능한 통신옵션에 대한 정보를 서버가 보내도록 요청.
그러므로 이에 대한 응답은, '클라이언트가 -> 서버에 어떻게 접속할지'에 대한 세부내용을 알려주는 헤더를 포함한다.
3) 안전하고 멱등한 메소드
3-1)안전한 메소드 : 서버의 관리자가, 클라리언트에게 쉽게 허용하는 메소드.
ex) get,head,option,trace
3-2)불안전한 메소드 : 서버에게 데이터전달 또는 상태를 변하게하는 메소드.
ex) post,put,delete
3-3)멱등한 메소드 : 동일한 메소드를 수없이 호출해도,한번만 요청한것과 같은 결과인 메소드.
❗post를 제외한 http의 모든 메소드가 멱등한 성질을 지님❗
- http 상태코드, 이유 구문
: 세자리로 구성되며, 첫째 자리가 특수한 의미를 갖음.
각 그룹에서 yy가 00인 코드는, 그 그룹의 기본적인, 일반적인 상태를 나타낸다.
만약 서버가 404라는 상태코드를 보냈지만, 클라이언트가 그걸 이해를 못한다면(?) 일반적인 400이라는
상태코드를 다시 보내줄것이다.
- 상태코드 형식: 1yy / 의미: 정보제공메시지 / 설명: 일반적인 정보 제공. 요청의 성공,실패 표시 x.
- 상태코드 형식: 2yy / 의미: 성공 / 설명: 서버가 메소드를 받았고 해석했으며, 정상적으로 수행한다는의미.
- 상태코드 형식: 3yy / 의미: 리다이렉션 / 설명: 성공적으로 작업을 마치기 전, 추가작업이 필요하다.
- 상태코드 형식: 4yy / 의미: 클라이언트 에러 / 설명: 요청이 잘못되었다. or 구문 오류 발생 or
기타 클라이언트 오류 발생해 수행 못한다..- 상태코드 형식: 5yy / 의미: 서버 에러 / 설명: 요청은 유효하나, 서버자체의 문제때문에 수행 못한다..
- http 공통 헤더 : 요청과 응답에 모두 사용되는 헤더.
- Date : http메시지가 만들어진 시각.
- COnnection : 현재 코드스테이츠에서도 그렇고 http/1.1을 사용하고있음. 기본적으로 keep-alive상태.
- Cache-Control
- Content-Length : 본문 크기를 바이트단위로 표시해줌.
- Content-type : 컨텐츠타입, 문자열 인코딩 명시가능.
*만약 프론트엔드에서 서버로 보낸다면,
text/html대신, www-url-form-encoded or multipart/form-data 등등이 될것임.
.
.
.
- http 요청 헤더
- host : 서버의 포트 포함 도메인 네임. **필수로 하나는 존재해야함!!!
- User-Agent : 어떤 클라이언트를 사용해 요청을 보낸건지 명시.
ex) User-Agent:Mozila/5.0 (Macintosh; Intel Mac OS X 10_13_5)이를 통해, 이 예시는 클라이언트가 맥북 크롬인것을 알수있다.
물론 헤더는 변경가능하므로 완전히 믿을수는없지만, 대부분 조작안하기때문에예를들어 이런걸로 접속자 통계를 낼수있다고한다. 이를 활용해 IE로 접속한사람도 알수있다.
때문에 IE로 접속한 유저에게 크롬으로 접속해주세요 라는 문구가 뜨는것도
이를 활용한 것이라고 보면된다.
- 렌더링 엔진?
- 위에서 썼듯이, 얘는 요청받은 콘텐츠, 내용을 브라우저화면에 표시해주는 역할을 한다.
- 플러그인, 브라우저 확장기능을 통해서 PDF와 같은 다른유형도 표시할수있다.
- 렌더링 엔진들
-
파이어폭스, 크롬, 사파리 는 두 종류의 렌더링엔진으로 제작되었다.
ex) 파이어폭스: 모질라에서 직접만든 게코(Gecko)엔진, 사파리와 크롬: 웹킷(Webkit)엔진**웹킷엔진: 최초 리눅스 플랫폼에서 동작하기위해 제작된 오픈소스엔진.
애플이 맥과 윈도우즈에서 사파리브라우저를 지원하기위해 수정을 하였음.
- 렌더링 엔진의 동작과정
보통 문서는 8kb 단위로 전송된다.
DOM트리 구축을 위한 html파싱!
: (1-1)html문서를 파싱하고, '콘텐츠트리'내부에서 태그를 DOM노드로 변환시킨다.
(1-2)외부 CSS파일과 함께 포함된 스타일요소들까지 파싱한다. 그리고 이때 '렌더트리'가 생성된다.렌더 트리 구축
: 색상 또는 면적과 같은 시각적 속성이 있는 사각형을 포함하고있다고 한다. 정해진 순서대로?
화면에 표시된다고 한다... 자세히 지금은 알 필요 없을듯..렌더 트리 배치
렌더 트리 그리기
browser security
브라우저에서 js로 할수있는것들
- ajax call을 해서 api를 호출할수있다.
- 다이나믹하게 dom을 제어할수있다.
- 인증정보를 브라우저에 저장할수있다.
- 인증정보를 불러올수있다.
브라우저는 csrf와 xss공격을 받을수있다.
xss: 클라이언트가 서버를 신뢰하기떄문에 발생하는 이슈
예) 서버에 메세지 요청 _> 메세지 응답 -> 응답받은 메세지 돔 반영 이 일반적인 메세지 방식인데
해킹자가 script태그로 감싼 에러코드를 여기에 메세지 text로 넣어서 이상한행동을 만든는것.
csrf: 서버는 인증정보를 갖고오먄 믿는다.
사용자는 인증정보를 가진채로 해커의 링크를 누르면,
해커가 인증정보르 ㄹ가로채서 서버에 요청을 보내버린다..
xss와 csrf는어떻게 막을수있을지를 셍각해보는게 좋다..
아직 유효한 xss방법을 알고있다면, 서버에 공격을 시도해보라.. 이번 스프린트에서!
cors : Cross-Origin resource sharing의 약자로, 도메인 또는 포트가 다른 서버의 자원을 요청하는 메커니즘.
이때 요청을 할 때에는 cross-origin HTTP에 의해 요청된다.
예를들어 http://domain-a.com으로부터 전송되는 html페이지가 </ img>src속성을 통해
XMLHttpRequest를 사용하여
http://domain-a.com/image.jpg를 요청하는경우가 있다.
오느랄 많은 웹페이지들은,
css 스타일시트,이미지 그리고 스크립트와 같은 리소스들을 각각의 출처로부터 읽어온다.
하지만 **동일 출처 정책(same-origin policy)때문에 cors같은 상황이발생시
외부서버에 요청한 데이터를 브라우저에서 보안목적으로 차단한다.
그로인해 정상적으로 데이터를 받을수없게 된다.
XMLHttpRequest, fetch API는 이 동일출처정책을 따르며,
이 api들을 사용하는 웹애플리케이션은 자신의 출처와 동일한 리소스만 불러올수있으며,
다른 출처의 리소스들을 불러오려면
그 출처에서 올바른 cors헤더를 포함한 응답을 response해야한다.
- preflight request
: 실질적인 요청 전에 option메소드를 통해 발생한다.
실제 요청이 안전한지 서버가 미리 파악할수있도록 하는 수단이다.
그리고 모든 cross origin요청이 이걸 발생시키는것이 아니다.
심플 리퀘스트를 실행하지못하면 프리플라이트가 실행된다.
**동일출처정책: 불러온 문서나 스크립트가, 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 중요한 보안방식임. 이것은 잠재적 악성문서를 격리한다.
