deep dive 브라우저의 랜더링 과정
뭘 만들려고하는데 어떻게 구조를 짜야할지 모르겟다... -> 이런컨설팅은 재미가 있다. 아이디어에 대해서 아키텍쳐를 잡아주니까
근데 그런건 10%도 안되고 90%는 서비스중인데 문제가있을때 한다.
새로 시작하는 프로젝트 하는 회사가는게 마음이 편할 수 있다.
노드는 쓰레드기반이 아니라 프로세스기반이라 cpu한장당 하나밖에 일 못한다.
메모리를 공유하기위해서는 Redis를 쓴다.
redis의 단점은 key value 모두 String 이라 string을 json.parse를 해야한다.
parse하는동안 error가 나거나 시간이 오래걸리면 뻑이난다.
---------------------------------------------------------------------------------------------------
<DOM>
-feat. HTML, HTTP
DOM이 뒤에 나오는 이유는 객체지향을 잘 알아야하기때문에 뒤에나오는것이다.
HTTP에 대해서 먼저한다
HTTP설명시작
Browser가 화면을 그리는것을 Rendering이라고 한다(밑그림) 색칠하는건 painting
밑그림을 올리기전에 미리 그 밑그림에 대한 내용들을 메모리에 올린다(Dom tree)
그다음 화면에 올린다 (그래서 화면그리는데까지 시간이 걸리는것)
최초에 브라우저에서 서버로 index.html을 가져오고 그 안에있는 정보로 css와 js, img를 가져오도록 서버에 다시 요청한다.
HTML 1.1에서는 하나씩 요청하고 받고 요청하고 받고 순차적으로 진행한다(그래서 느리다) <<- pooling방식이다. 아파치등등에서 keep arrive하면 커넥션을 클로즈하지않고 기다린다. -> 근데 keep arrive하면 빠른데 동시접속자 문제가 생긴다. (큐에 쌓이기때문)
그래서 HTML 2가 나왔다 . (서버들은 keep Arrive를 꺼려하기떄문 -> keep arrive를 디폴트 true로 함)
HTML2에서는 요청을 병렬로 보내게 된다(여러개의 커넥션을 맺는것);
근데 이렇게되면 문제가 dom보다 css가 먼저 받아진다던가 js가 먼저 받아져서 바로 못그리는 현상이 일어났다.
tomcat은 요청과 응답을 하나의 thread로 만든다 (java)
nginx는 process기반이다 (요청응답당 프로세스를 만든다)
모든게 다 casecading이다 (위에서 아래로 읽어온다)
stream으로 이미지를 주면 이미지를 먼저 보여줄수잇다(흐리더라도)
<streaming방식이란?>
그냥 데이터를 주면 그 데이터의 크기만큼 메모리에 올려야한다.
그래서 데이터를 쪼개서 조금씩 보내주는방식이다 (요즘은 다 그렇다)
buffer라는것이 있다(지정된 용량의 공간) 그 공간이 다 차면 streaming으로 준다
호스로 데이터를 흘려보내는데 이 호스의 두께를 대역폭이라고 한다.
스트리밍으로 버퍼사이즈만큼 내려주는게 스트리밍이고
이런애들을 TCP/IP라고 한다.
버퍼가 차야 보내는데 버퍼가 바쁘면 걸리는게 버퍼링이다.
파일을 되는대로 읽어주는게 TCP/IP방식이다.
데이터를 디스크에 순차적으로 쓸 수 없다( 중간중간 추가될수있기때문에)
그래서 그 디스크에 적힌 내용의 위치를 알아야하는게 Head Sector라는것이다.
데이터를 여러곳에쓰다보면 가까운데부터 읽다보면 페이지 순서대로읽지 않게된다.
이렇게 순서가 맞지않지만 받은 데이터들을 merge하는 시간이 걸린다(정렬하는시간이 필요하다)
이렇게 쪼개서 내려가는 방식을 TCP/IP라고 한다.
NGINX에서 동시에 받을수 있는 숫자는 어떻게 계산할수있을까?
CPU의 장수에 따라서 한번에 받을수있는 사람의 수가 있다.
큐사이즈를 초과하면 서버가 죽어버린다.
NGINX는 서빙하는 알바생이다
NODE는 주방장이다
주방장이 요리하는시간이 오래걸리기때문에 서빙하는 알바생이 보통 논다 (NGINX가 보통놈)
그래서 NGINX에서 큐에 대기할수있는 수를 지정할 수 있다.
똑같은 id에 write가 동시에 여러개 걸리면 write lock이 걸린다. 그래서 웨이팅이 걸리고 순서대로 일처리를 하게된다.
delete는 table lock이 걸린다 왜냐하면 row의 수가 바뀌기때문에..
<DOM>
HTML은 XML기반이다
그래서 XHTML이라고 한다. ->나중에 HTML로 통일됨
HTML에서는 Tag라고 부르지만 XML에서는 Element라고 부른다
| XML | HTML |
| Element | Tag |
| Attribute | Attribute |
| Text | Text (ContentText) |
XML은 NameSpace가 있다 (같은데이터라도 표현방식이 달라질 수 있기떄문)
Document에서 가장 처음에 있는것을 rootElement라고 한다(HTML태그)
루트에서 점점 퍼지는 방식은 자료구조 tree형식을 가지고있기때문에 dom tree구조라고하고
제일 마지막 노드를 leaf node라고 한다.
comment도 하나의 엘리먼트이다.
attribute는 쌍따옴표가 표준이다 JSX는 상관없지만.. 그래서 가급적 쌍따옴표를 써주자.
ECMAS에서는 객체의 메서드에 대한 인터페이스만 정의해두엇다.
코드기반으로 무조건 가는게 아니라 합리성을 따져서 설계를 해야한다
그래서 element가 document를 상속받는게 아니라 node를 상속받아서 getElementByTagName을 구현하는것
모든 Node는 Event를 갖는다.
Event를 받는 애들은 모두 EventTarget이라는것을 상속받는다.
*조금 헷갈리는것이 있다
HTMLCollection이라는것과 NodeList라는것이 있다.
셀렉터로 고를때 진짜 Array가 아니라 유사어레이로 나오는 이유는 노드의 기능들을 쓰기 위해서이다.
HTMLCollection과 NodeList는 이터러블 객체다.
DOMPurify라는 라이브러리가 있는데 여기서 sanitite함수를 쓰면 HTML을 한번 솎아낸다.
진짜 많이쓰는것중하나!
dom.classList.toggle('클래스명' , [boolean]) ; 클래스를 추가제거한다
ComputedProperty => 값이 바꼇는지 안바꼇는지 아는것 (옵저빙)
예전에는 양방향 컴퓨티드 프로퍼티를 햇는데 무한루프가 발생해서 요즘은 단방향을씀
window.getComputedStyle(돔) -> 바뀌는게 다끝난상태의 클래스리스트를 주세요 하는것이다.