.. Copyright (c) 2016-2018 Varnish Software AS SPDX-License-Identifier: BSD-2-Clause See LICENSE file for full text of license .. _phk_firstdesign: =========================== The first design of Varnish =========================== I have been working on a "bit-storage" facility for datamuseum.dk, and as part of my "eat your own dog-food" policy, I converting my own personal archive (41 DVD's worth) as a test. Along the way I passed through 2006 and found some files from the birth of Varnish 10 years ago. The first Varnish Design notes ------------------------------ This file are notes taken during a meeting in Oslo on 2nd Feb 2006, which in essence consisted of Anders Berg cursing Squid for a couple of hours. (Originally the meeting was scheduled for Jan 24th but a SAS pilot strike put an end to that.) To be honest I knew very little about web-traffic, my own homepage was written in HTML in vi(1), so I had a bit of catching up to do on that front, but the overall job was pretty simple: A program to move bytes ... fast. It is quite interesting to see how many things we got right and where we kept thinking in the old frame of reference (ie: Squid):: Notes on Varnish ---------------- Collected 2006-02-02 to 2006-02-.. Poul-Henning Kamp Philosophy ---------- It is not enough to deliver a technically superior piece of software, if it is not possible for people to deploy it usefully in a sensible way and timely fashion. Deployment scenarios -------------------- There are two fundamental usage scenarios for Varnish: when the first machine is brought up to offload a struggling backend and when a subsequent machine is brought online to help handle the load. The first (layer of) Varnish ---------------------------- Somebody's webserver is struggling and they decide to try Varnish. Often this will be a skunkworks operation with some random PC purloined from wherever it wasn't being used and the Varnish "HOWTO" in one hand. If they do it in an orderly fashion before things reach panic proportions, a sensible model is to setup the Varnish box, test it out from your own browser, see that it answers correctly. Test it some more and then add the IP# to the DNS records so that it takes 50% of the load off the backend. If it happens as firefighting at 3AM the backend will be moved to another IP, the Varnish box given the main IP and things had better work real well, really fast. In both cases, it would be ideal if all that is necessary to tell Varnish are two pieces of information: Storage location Alternatively we can offer an "auto" setting that makes Varnish discover what is available and use what it find. DNS or IP# of backend. IP# is useful when the DNS settings are not quite certain or when split DNS horizon setups are used. Ideally this can be done on the commandline so that there is no configuration file to edit to get going, just varnish -d /home/varnish -s backend.example.dom and you're off running. A text, curses or HTML based facility to give some instant feedback and stats is necessary. If circumstances are not conductive to structured approach, it should be possible to repeat this process and set up N independent Varnish boxes and get some sort of relief without having to read any further documentation. The subsequent (layers of) Varnish ---------------------------------- This is what happens once everybody has caught their breath, and where we start to talk about Varnish clusters. We can assume that at this point, the already installed Varnish machines have been configured more precisely and that people have studied Varnish configuration to some level of detail. When Varnish machines are put in a cluster, the administrator should be able to consider the cluster as a unit and not have to think and interact with the individual nodes. Some sort of central management node or facility must exist and it would be preferable if this was not a physical but a logical entity so that it can follow the admin to the beach. Ideally it would give basic functionality in any browser, even mobile phones. The focus here is scaleability, we want to avoid per-machine configuration if at all possible. Ideally, preconfigured hardware can be plugged into power and net, find an address with DHCP, contact preconfigured management node, get a configuration and start working. But we also need to think about how we avoid a site of Varnish machines from acting like a stampeeding horde when the power or connectivity is brought back after a disruption. Some sort of slow starting ("warm-up" ?) must be implemented to prevent them from hitting all the backend with the full force. An important aspect of cluster operations is giving a statistically meaningful judgement of the cluster size, in particular answering the question "would adding another machine help ?" precisely. We should have a facility that allows the administrator to type in a REGEXP/URL and have all the nodes answer with a checksum, age and expiry timer for any documents they have which match. The results should be grouped by URL and checksum. Technical concepts ------------------ We want the central Varnish process to be that, just one process, and we want to keep it small and efficient at all cost. Code that will not be used for the central functionality should not be part of the central process. For instance code to parse, validate and interpret the (possibly) complex configuration file should be a separate program. Depending on the situation, the Varnish process can either invoke this program via a pipe or receive the ready to use data structures via a network connection. Exported data from the Varnish process should be made as cheap as possible, likely shared memory. That will allow us to deploy separate processes for log-grabbing, statistics monitoring and similar "off-duty" tasks and let the central process get on with the important job. Backend interaction ------------------- We need a way to tune the backend interaction further than what the HTTP protocol offers out of the box. We can assume that all documents we get from the backend has an expiry timer, if not we will set a default timer (configurable of course). But we need further policy than that. Amongst the questions we have to ask are: How long time after the expiry can we serve a cached copy of this document while we have reason to believe the backend can supply us with an update ? How long time after the expiry can we serve a cached copy of this document if the backend does not reply or is unreachable. If we cannot serve this document out of cache and the backend cannot inform us, what do we serve instead (404 ? A default document of some sort ?) Should we just not serve this page at all if we are in a bandwidth crush (DoS/stampede) situation ? It may also make sense to have a "emergency detector" which triggers when the backend is overloaded and offer a scaling factor for all timeouts for when in such an emergency state. Something like "If the average response time of the backend rises above 10 seconds, multiply all expiry timers by two". It probably also makes sense to have a bandwidth/request traffic shaper for backend traffic to prevent any one Varnish machine from pummeling the backend in case of attacks or misconfigured expiry headers. Startup/consistency ------------------- We need to decide what to do about the cache when the Varnish process starts. There may be a difference between it starting first time after the machine booted and when it is subsequently (re)started. By far the easiest thing to do is to disregard the cache, that saves a lot of code for locating and validating the contents, but this carries a penalty in backend or cluster fetches whenever a node comes up. Lets call this the "transient cache model" The alternative is to allow persistently cached contents to be used according to configured criteria: Can expired contents be served if we can't contact the backend ? (dangerous...) Can unexpired contents be served if we can't contact the backend ? If so, how much past the expiry ? It is a very good question how big a fraction of the persistent cache would be usable after typical downtimes: After a Varnish process restart: Nearly all. After a power-failure ? Probably at least half, but probably not the half that contains the most busy pages. And we need to take into consideration if validating the format and contents of the cache might take more resources and time than getting the content from the backend. Off the top of my head, I would prefer the transient model any day because of the simplicity and lack of potential consistency problems, but if the load on the back end is intolerable this may not be practically feasible. The best way to decide is to carefully analyze a number of cold starts and cache content replacement traces. The choice we make does affect the storage management part of Varnish, but I see that is being modular in any instance, so it may merely be that some storage modules come up clean on any start while other will come up with existing objects cached. Clustering ---------- I'm somewhat torn on clustering for traffic purposes. For admin and management: Yes, certainly, but starting to pass objects from one machine in a cluster to another is likely to be just be a waste of time and code. Today one can trivially fit 1TB into a 1U machine so the partitioning argument for cache clusters doesn't sound particularly urgent to me. If all machines in the cluster have sufficient cache capacity, the other remaining argument is backend offloading, that would likely be better mitigated by implementing a 1:10 style two-layer cluster with the second level node possibly having twice the storage of the front row nodes. The coordination necessary for keeping track of, or discovering in real-time, who has a given object can easily turn into a traffic and cpu load nightmare. And from a performance point of view, it only reduces quality: First we send out a discovery multicast, then we wait some amount of time to see if a response arrives only then should we start to ask the backend for the object. With a two-level cluster we can ask the layer-two node right away and if it doesn't have the object it can ask the back-end right away, no timeout is involved in that. Finally Consider the impact on a cluster of a "must get" object like an IMG tag with a misspelled URL. Every hit on the front page results in one get of the wrong URL. One machine in the cluster ask everybody else in the cluster "do you have this URL" every time somebody gets the frontpage. If we implement a negative feedback protocol ("No I don't"), then each hit on the wrong URL will result in N+1 packets (assuming multicast). If we use a silent negative protocol the result is less severe for the machine that got the request, but still everybody wakes up to to find out that no, we didn't have that URL. Negative caching can mitigate this to some extent. Privacy ------- Configuration data and instructions passed forth and back should be encrypted and signed if so configured. Using PGP keys is a very tempting and simple solution which would pave the way for administrators typing a short ascii encoded pgp signed message into a SMS from their Bahamas beach vacation... Implementation ideas -------------------- The simplest storage method mmap(2)'s a disk or file and puts objects into the virtual memory on page aligned boundaries, using a small struct for metadata. Data is not persistent across reboots. Object free is incredibly cheap. Object allocation should reuse recently freed space if at all possible. "First free hole" is probably a good allocation strategy. Sendfile can be used if filebacked. If nothing else disks can be used by making a 1-file filesystem on them. More complex storage methods are object per file and object in database models. They are relatively trivial and well understood. May offer persistence. Read-Only storage methods may make sense for getting hold of static emergency contents from CD-ROM etc. Treat each disk arm as a separate storage unit and keep track of service time (if possible) to decide storage scheduling. Avoid regular expressions at runtime. If config file contains regexps, compile them into executable code and dlopen() it into the Varnish process. Use versioning and refcounts to do memory management on such segments. Avoid committing transmit buffer space until we have bandwidth estimate for client. One possible way: Send HTTP header and time ACKs getting back, then calculate transmit buffer size and send object. This makes DoS attacks more harmless and mitigates traffic stampedes. Kill all TCP connections after N seconds, nobody waits an hour for a web-page to load. Abuse mitigation interface to firewall/traffic shaping: Allow the central node to put an IP/Net into traffic shaping or take it out of traffic shaping firewall rules. Monitor/interface process (not main Varnish process) calls script to config firewalling. "Warm-up" instructions can take a number of forms and we don't know what is the most efficient or most usable. Here are some ideas: Start at these URL's then... ... follow all links down to N levels. ... follow all links that match REGEXP no deeper than N levels down. ... follow N random links no deeper than M levels down. ... load N objects by following random links no deeper than M levels down. But... ... never follow any links that match REGEXP ... never pick up objects larger than N bytes ... never pick up objects older than T seconds It makes a lot of sense to not actually implement this in the main Varnish process, but rather supply a template perl or python script that primes the cache by requesting the objects through Varnish. (That would require us to listen separately on 127.0.0.1 so the perlscript can get in touch with Varnish while in warm-up.) One interesting but quite likely overengineered option in the cluster case is if the central monitor tracks a fraction of the requests through the logs of the running machines in the cluster, spots the hot objects and tell the warming up varnish what objects to get and from where. In the cluster configuration, it is probably best to run the cluster interaction in a separate process rather than the main Varnish process. From Varnish to cluster info would go through the shared memory, but we don't want to implement locking in the shmem so some sort of back-channel (UNIX domain or UDP socket ?) is necessary. If we have such an "supervisor" process, it could also be tasked with restarting the varnish process if vitals signs fail: A time stamp in the shmem or kill -0 $pid. It may even make sense to run the "supervisor" process in stand alone mode as well, there it can offer a HTML based interface to the Varnish process (via shmem). For cluster use the user would probably just pass an extra argument when he starts up Varnish: varnish -c $cluster_args $other_args vs varnish $other_args and a "varnish" shell script will Do The Right Thing. Shared memory ------------- The shared memory layout needs to be thought about somewhat. On one hand we want it to be stable enough to allow people to write programs or scripts that inspect it, on the other hand doing it entirely in ascii is both slow and prone to race conditions. The various different data types in the shared memory can either be put into one single segment(= 1 file) or into individual segments (= multiple files). I don't think the number of small data types to be big enough to make the latter impractical. Storing the "big overview" data in shmem in ASCII or HTML would allow one to point cat(1) or a browser directly at the mmaped file with no interpretation necessary, a big plus in my book. Similarly, if we don't update them too often, statistics could be stored in shared memory in perl/awk friendly ascii format. But the logfile will have to be (one or more) FIFO logs, probably at least three in fact: Good requests, Bad requests, and exception messages. If we decide to make logentries fixed length, we could make them ascii so that a simple "sort -n /tmp/shmem.log" would put them in order after a leading numeric timestamp, but it is probably better to provide a utility to cat/tail-f the log and keep the log in a bytestring FIFO format. Overruns should be marked in the output. *END* The second Varnish Design notes ------------------------------- You will notice above that there is no mention of VCL, it took a couple of weeks for that particular lightning to strike. Interestingly I know exactly where the lightning came from, and what it hit. The timeframe was around GCC 4.0.0 which was not their best release, and I had for some time been pondering a pre-processor for the C language to make up for the ISO-C stagnation and braindamage. I've read most of the "classic" compiler books, and probably read more compilers many people (Still to go: `GIER Algol 4 `_) but to be honest I found them far too theoretical and not very helpful from a *practical* compiler construction point of view. But there is one compiler-book which takes an entirely different take: `Hanson and Fraser's LCC book. `_ which throws LEX and YACC under the truck and concentrates on compiling. Taking their low-down approach to parsing, and emitting C code, there really isn't much compiler left to write, and I had done several interesting hacks towards my 'K' language. The lightning rod was all the ideas Anders had for how Varnish should be able to manipulate the traffic passing through, how to decide what to cache, how long time to cache it, where to cache it and ... it sounded like a lot of very detailed code which had to be incredibly configurable. Soon those two inspirations collided:: Notes on Varnish ---------------- Collected 2006-02-24 to 2006-02-.. Poul-Henning Kamp ----------------------------------------------------------------------- Policy Configuration Policy is configured in a simple unidirectional (no loops, no goto) programming language which is compiled into 'C' and from there binary modules which are dlopen'ed by the main Varnish process. The dl object contains one exported symbol, a pointer to a structure which contains a reference count, a number of function pointers, a couple of string variables with identifying information. All access into the config is protected by the reference counts. Multiple policy configurations can be loaded at the same time but only one is the "active configuration". Loading, switching and unloading of policy configurations happen via the management process. A global config sequence number is incremented on each switch and policy modified object attributes (ttl, cache/nocache) are all qualified by the config-sequence under which they were calculated and invalid if a different policy is now in effect. ----------------------------------------------------------------------- Configuration Language XXX: include lines. BNF: program: function | program function function: "sub" function_name compound_statement compound_statement: "{" statements "}" statements: /* empty */ | statement | statements statement statement: if_statement | call_statement | "finish" | assignment_statement | action_statement if_statement: "if" condition compound_statement elif_parts else_part elif_parts: /* empty */ | elif_part | elif_parts elif_part elif_part: "elseif" condition compound_statement | "elsif" condition compound_statement | "else if" condition compound_statement else_part: /* empty */ | "else" compound_statement call_statement: "call" function_name assign_statement: field "=" value field: object field "." variable action_statement: action arguments arguments: /* empty */ arguments | argument ----------------------------------------------------------------------- Sample request policy program sub request_policy { if (client.ip in 10.0.0.0/8) { no-cache finish } if (req.url.host ~ "cnn.no$") { rewrite s/cnn.no$/vg.no/ } if (req.url.path ~ "cgi-bin") { no-cache } if (req.useragent ~ "spider") { no-new-cache } if (backend.response_time > 0.8s) { set req.ttlfactor = 1.5 } elseif (backend.response_time > 1.5s) { set req.ttlfactor = 2.0 } elseif (backend.response_time > 2.5s) { set req.ttlfactor = 5.0 } /* * the program contains no references to * maxage, s-maxage and expires, so the * default handling (RFC2616) applies */ } ----------------------------------------------------------------------- Sample fetch policy program sub backends { set backend.vg.ip = {...} set backend.ads.ip = {...} set backend.chat.ip = {...} set backend.chat.timeout = 10s set backend.chat.bandwidth = 2000 MB/s set backend.other.ip = {...} } sub vg_backend { set backend.ip = {10.0.0.1-5} set backend.timeout = 4s set backend.bandwidth = 2000Mb/s } sub fetch_policy { if (req.url.host ~ "/vg.no$/") { set req.backend = vg call vg_backend } else { /* XXX: specify 404 page url ? */ error 404 } if (backend.response_time > 2.0s) { if (req.url.path ~ "/landbrugspriser/") { error 504 } } fetch if (backend.down) { if (obj.exist) { set obj.ttl += 10m finish } switch_config ohhshit } if (obj.result == 404) { error 300 "http://www.vg.no" } if (obj.result != 200) { finish } if (obj.size > 256k) { no-cache } else if (obj.size > 32k && obj.ttl < 2m) { obj.tll = 5m } if (backend.response_time > 2.0s) { set ttl *= 2.0 } } sub prefetch_policy { if (obj.usage < 10 && obj.ttl < 5m) { fetch } } ----------------------------------------------------------------------- Purging When a purge request comes in, the regexp is tagged with the next generation number and added to the tail of the list of purge regexps. Before a sender transmits an object, it is checked against any purge-regexps which have higher generation number than the object and if it matches the request is sent to a fetcher and the object purged. If there were purge regexps with higher generation to match, but they didn't match, the object is tagged with the current generation number and moved to the tail of the list. Otherwise, the object does not change generation number and is not moved on the generation list. New Objects are tagged with the current generation number and put at the tail of the list. Objects are removed from the generation list when deleted. When a purge object has a lower generation number than the first object on the generation list, the purge object has been completed and will be removed. A log entry is written with number of compares and number of hits. ----------------------------------------------------------------------- Random notes swap backed storage slowstart by config-flipping start-config has peer servers as backend once hitrate goes above limit, management process flips config to 'real' config. stat-object always URL, not regexp management + varnish process in one binary, comms via pipe Change from config with long expiry to short expiry, how does the ttl drop ? (config sequence number invalidates all calculated/modified attributes.) Mgt process holds copy of acceptor socket -> Restart without lost client requests. BW limit per client IP: create shortlived object (<4sec) to hold status. Enforce limits by delaying responses. ----------------------------------------------------------------------- Source structure libvarnish library with interface facilities, for instance functions to open&read shmem log varnish varnish sources in three classes ----------------------------------------------------------------------- protocol cluster/mgt/varnish object_query url -> TTL, size, checksum {purge,invalidate} regexp object_status url -> object metadata load_config filename switch_config configname list_configs unload_config freeze # stop the clock, freezes the object store thaw suspend # stop acceptor accepting new requests resume stop # forced stop (exits) varnish process start restart = "stop;start" ping $utc_time -> pong $utc_time # cluster only config_contents filename $inline -> compilation messages stats [-mr] -> $data zero stats help ----------------------------------------------------------------------- CLI (local) import protocol from above telnet localhost someport authentication: password $secret secret stored in {/usr/local}/etc/varnish.secret (400 root:wheel) ----------------------------------------------------------------------- HTML (local) php/cgi-bin thttpd ? (alternatively direct from C-code.) Everything the CLI can do + stats popen("rrdtool"); log view ----------------------------------------------------------------------- CLI (cluster) import protocol from above, prefix machine/all compound stats accept / deny machine (?) curses if you set termtype ----------------------------------------------------------------------- HTML (cluster) ditto ditto http://clustercontrol/purge?regexp=fslkdjfslkfdj POST with list of regexp authentication ? (IP access list) ----------------------------------------------------------------------- Mail (cluster) pgp signed emails with CLI commands ----------------------------------------------------------------------- connection varnish -> cluster controller Encryption SSL Authentication (?) IP number checks. varnish -c clusterid -C mycluster_ctrl.vg.no ----------------------------------------------------------------------- Filer /usr/local/sbin/varnish contains mgt + varnish process. if -C argument, open SSL to cluster controller. Arguments: -p portnumber -c clusterid@cluster_controller -f config_file -m memory_limit -s kind[,storage-options] -l logfile,logsize -b backend ip... -d debug -u uid -a CLI_port KILL SIGTERM -> suspend, stop /usr/local/sbin/varnish_cluster Cluster controller. Use syslog Arguments: -f config file -d debug -u uid (?) /usr/local/sbin/varnish_logger Logfile processor -i shmemfile -e regexp -o "/var/log/varnish.%Y%m%d.traffic" -e regexp2 -n "/var/log/varnish.%Y%m%d.exception" (NCSA format) -e regexp3 -s syslog_level,syslogfacility -r host:port send via TCP, prefix hostname SIGHUP: reopen all files. /usr/local/bin/varnish_cli Command line tool. /usr/local/share/varnish/etc/varnish.conf default request + fetch + backend scripts /usr/local/share/varnish/etc/rfc2616.conf RFC2616 compliant handling function /usr/local/etc/varnish.conf (optional) request + fetch + backend scripts /usr/local/share/varnish/etc/varnish.startup default startup sequence /usr/local/etc/varnish.startup (optional) startup sequence /usr/local/etc/varnish_cluster.conf XXX {/usr/local}/etc/varnish.secret CLI password file. ----------------------------------------------------------------------- varnish.startup load config /foo/bar startup_conf switch config startup_conf !mypreloadscript load config /foo/real real_conf switch config real_conf resume The third Varnish Design notes ------------------------------- A couple of days later the ideas had gel'ed:: Notes on Varnish ---------------- Collected 2006-02-26 to 2006-03-.. Poul-Henning Kamp ----------------------------------------------------------------------- Objects available to functions in VCL client # The client req # The request obj # The object from which we satisfy it backend # The chosen supplier ----------------------------------------------------------------------- Configuration Language XXX: declare IP lists ? BNF: program: part | program part part: "sub" function_name compound | "backend" backend_name compound compound: "{" statements "}" statements: /* empty */ | statement | statements statement statement: conditional | functioncall | "set" field value | field "=" value | "no_cache" | "finish" | "no_new_cache" | call function_name | fetch | error status_code | error status_code string(message) | switch_config config_id | rewrite field string(match) string(replace) conditional: "if" condition compound elif_parts else_part elif_parts: /* empty */ | elif_part | elif_parts elif_part elif_part: "elseif" condition compound | "elsif" condition compound | "else if" condition compound else_part: /* empty */ | "else" compound functioncall: "call" function_name field: object field "." variable condition: '(' cond_or ')' cond_or: cond_and | cond_or '||' cond_and cond_and: cond_part | cond_and '&&' cond_part cond_part: '!' cond_part2 | cond_part2 cond_part2: condition | field(int) '<' number | field(int) '<=' number | field(int) '>' number | field(int) '>=' number | field(int) '=' number | field(int) '!=' number | field(IP) ~ ip_list | field(string) ~ string(regexp) ----------------------------------------------------------------------- Sample request policy program sub request_policy { if (client.ip in 10.0.0.0/8) { no-cache finish } if (req.url.host ~ "cnn.no$") { rewrite s/cnn.no$/vg.no/ } if (req.url.path ~ "cgi-bin") { no-cache } if (req.useragent ~ "spider") { no-new-cache } if (backend.response_time > 0.8s) { set req.ttlfactor = 1.5 } elseif (backend.response_time > 1.5s) { set req.ttlfactor = 2.0 } elseif (backend.response_time > 2.5s) { set req.ttlfactor = 5.0 } /* * the program contains no references to * maxage, s-maxage and expires, so the * default handling (RFC2616) applies */ } ----------------------------------------------------------------------- Sample fetch policy program sub backends { set backend.vg.ip = {...} set backend.ads.ip = {...} set backend.chat.ip = {...} set backend.chat.timeout = 10s set backend.chat.bandwidth = 2000 MB/s set backend.other.ip = {...} } sub vg_backend { set backend.ip = {10.0.0.1-5} set backend.timeout = 4s set backend.bandwidth = 2000Mb/s } sub fetch_policy { if (req.url.host ~ "/vg.no$/") { set req.backend = vg call vg_backend } else { /* XXX: specify 404 page url ? */ error 404 } if (backend.response_time > 2.0s) { if (req.url.path ~ "/landbrugspriser/") { error 504 } } fetch if (backend.down) { if (obj.exist) { set obj.ttl += 10m finish } switch_config ohhshit } if (obj.result == 404) { error 300 "http://www.vg.no" } if (obj.result != 200) { finish } if (obj.size > 256k) { no-cache } else if (obj.size > 32k && obj.ttl < 2m) { obj.tll = 5m } if (backend.response_time > 2.0s) { set ttl *= 2.0 } } sub prefetch_policy { if (obj.usage < 10 && obj.ttl < 5m) { fetch } } ----------------------------------------------------------------------- Purging When a purge request comes in, the regexp is tagged with the next generation number and added to the tail of the list of purge regexps. Before a sender transmits an object, it is checked against any purge-regexps which have higher generation number than the object and if it matches the request is sent to a fetcher and the object purged. If there were purge regexps with higher generation to match, but they didn't match, the object is tagged with the current generation number and moved to the tail of the list. Otherwise, the object does not change generation number and is not moved on the generation list. New Objects are tagged with the current generation number and put at the tail of the list. Objects are removed from the generation list when deleted. When a purge object has a lower generation number than the first object on the generation list, the purge object has been completed and will be removed. A log entry is written with number of compares and number of hits. ----------------------------------------------------------------------- Random notes swap backed storage slowstart by config-flipping start-config has peer servers as backend once hitrate goes above limit, management process flips config to 'real' config. stat-object always URL, not regexp management + varnish process in one binary, comms via pipe Change from config with long expiry to short expiry, how does the ttl drop ? (config sequence number invalidates all calculated/modified attributes.) Mgt process holds copy of acceptor socket -> Restart without lost client requests. BW limit per client IP: create shortlived object (<4sec) to hold status. Enforce limits by delaying responses. ----------------------------------------------------------------------- Source structure libvarnish library with interface facilities, for instance functions to open&read shmem log varnish varnish sources in three classes ----------------------------------------------------------------------- protocol cluster/mgt/varnish object_query url -> TTL, size, checksum {purge,invalidate} regexp object_status url -> object metadata load_config filename switch_config configname list_configs unload_config freeze # stop the clock, freezes the object store thaw suspend # stop acceptor accepting new requests resume stop # forced stop (exits) varnish process start restart = "stop;start" ping $utc_time -> pong $utc_time # cluster only config_contents filename $inline -> compilation messages stats [-mr] -> $data zero stats help ----------------------------------------------------------------------- CLI (local) import protocol from above telnet localhost someport authentication: password $secret secret stored in {/usr/local}/etc/varnish.secret (400 root:wheel) ----------------------------------------------------------------------- HTML (local) php/cgi-bin thttpd ? (alternatively direct from C-code.) Everything the CLI can do + stats popen("rrdtool"); log view ----------------------------------------------------------------------- CLI (cluster) import protocol from above, prefix machine/all compound stats accept / deny machine (?) curses if you set termtype ----------------------------------------------------------------------- HTML (cluster) ditto ditto http://clustercontrol/purge?regexp=fslkdjfslkfdj POST with list of regexp authentication ? (IP access list) ----------------------------------------------------------------------- Mail (cluster) pgp signed emails with CLI commands ----------------------------------------------------------------------- connection varnish -> cluster controller Encryption SSL Authentication (?) IP number checks. varnish -c clusterid -C mycluster_ctrl.vg.no ----------------------------------------------------------------------- Filer /usr/local/sbin/varnish contains mgt + varnish process. if -C argument, open SSL to cluster controller. Arguments: -p portnumber -c clusterid@cluster_controller -f config_file -m memory_limit -s kind[,storage-options] -l logfile,logsize -b backend ip... -d debug -u uid -a CLI_port KILL SIGTERM -> suspend, stop /usr/local/sbin/varnish_cluster Cluster controller. Use syslog Arguments: -f config file -d debug -u uid (?) /usr/local/sbin/varnish_logger Logfile processor -i shmemfile -e regexp -o "/var/log/varnish.%Y%m%d.traffic" -e regexp2 -n "/var/log/varnish.%Y%m%d.exception" (NCSA format) -e regexp3 -s syslog_level,syslogfacility -r host:port send via TCP, prefix hostname SIGHUP: reopen all files. /usr/local/bin/varnish_cli Command line tool. /usr/local/share/varnish/etc/varnish.conf default request + fetch + backend scripts /usr/local/share/varnish/etc/rfc2616.conf RFC2616 compliant handling function /usr/local/etc/varnish.conf (optional) request + fetch + backend scripts /usr/local/share/varnish/etc/varnish.startup default startup sequence /usr/local/etc/varnish.startup (optional) startup sequence /usr/local/etc/varnish_cluster.conf XXX {/usr/local}/etc/varnish.secret CLI password file. ----------------------------------------------------------------------- varnish.startup load config /foo/bar startup_conf switch config startup_conf !mypreloadscript load config /foo/real real_conf switch config real_conf resume Fourth Varnish Design Note -------------------------- You'd think we'd be cookin' with gas now, and indeed we were, but now all the difficult details started to raise ugly questions, and it has never stopped since:: Questions: * Which "Host:" do we put in the request to the backend ? The one we got from the client ? The ip/dns-name of the backend ? Configurable in VCL backend declaration ? (test with www.ing.dk) * Construction of headers for queries to backend ? How much do we take from client headers, how much do we make up ? Some sites discriminate contents based on User-Agent header. (test with www.krak.dk/www.rs-components.dk) Cookies * Mapping of headers from backend reply to the reply to client Which fields come from the backend ? Which fields are made up on the spot ? (expiry time ?) (Static header fields can be prepended to contents in storage) * 3xx replies from the backend Does varnish follow a redirection or do we pass it to the client ? Do we cache 3xx replies ? The first live traffic ---------------------- The final bit of history I want to share is the IRC log from the first time tried to put real live traffic through Varnish. The language is interscandinavian, but I think non-vikings can get still get the drift:: **** BEGIN LOGGING AT Thu Jul 6 12:36:48 2006 Jul 06 12:36:48 * Now talking on #varnish Jul 06 12:36:48 * EvilDES gives channel operator status to andersb Jul 06 12:36:53 * EvilDES gives channel operator status to phk Jul 06 12:36:53 hehe Jul 06 12:36:56 s?nn Jul 06 12:37:00 Jepps, er dere klare? Jul 06 12:37:08 Jeg har varnish oppe og k?re med leonora som backend. Jul 06 12:37:12 * EvilDES has changed the topic to: Live testing in progress! Jul 06 12:37:16 * EvilDES sets mode +t #varnish Jul 06 12:37:19 Da setter jeg p? trafikk Jul 06 12:37:36 andersb: kan du starte med bare at give us trafiik i 10 sekunder eller s? ? Jul 06 12:37:49 * edward (edward@f95.linpro.no) has joined #varnish Jul 06 12:38:32 hmm, f?rst m? jeg f? trafikk dit. Jul 06 12:38:55 Har noe kommet? Eller har det blitt suprt etter /systemmeldinger/h.html som er helsefilen? Jul 06 12:39:10 s/suprt/spurt/ Jul 06 12:39:41 ser ingenting Jul 06 12:39:45 jeg har ikke set noget endnu... Jul 06 12:40:35 den pr?ver p? port 80 Jul 06 12:41:24 okay.. Jul 06 12:41:31 kan vi ikke bare kj?re varnishd p? port 80? Jul 06 12:41:46 ok, jeg ville bare helst ikke k?re som root. Jul 06 12:41:47 Pr?ver den noe annet n?? Jul 06 12:41:59 nej stadig 80. Jul 06 12:42:03 Jeg starter varnishd som root Jul 06 12:42:08 nei, vent Jul 06 12:42:08 Topp Jul 06 12:42:11 okay Jul 06 12:42:15 kom det 8080 n?? Jul 06 12:42:18 sysctl reserved_port Jul 06 12:43:04 okay? F?r dere 8080 trafikk n?? Jul 06 12:43:08 sysctl net.inet.ip.portrange.reservedhigh=79 Jul 06 12:44:41 Okay, avventer om vi skal kj?re 8080 eller 80. Jul 06 12:45:56 starter den p? port 80 som root Jul 06 12:46:01 den k?rer nu Jul 06 12:46:01 Okay, vi har funnet ut at m?ten jeg satte 8080 p? i lastbalanserern var feil. Jul 06 12:46:07 okay p? 80? Jul 06 12:46:12 vi k?rer Jul 06 12:46:14 ja, masse trafikk Jul 06 12:46:29 omtrent 100 req/sec Jul 06 12:46:37 and we're dead... Jul 06 12:46:40 stopp! Jul 06 12:46:58 den stopper automatisk. Jul 06 12:47:04 Vi kan bare kj?re det slik. Jul 06 12:47:06 tok noen sekunder Jul 06 12:47:20 Npr den begynner svar p? 80 s? vil lastbalanserern finne den fort og sende trafikk. Jul 06 12:47:41 ca 1500 connection requests kom inn f?r den sluttet ? sende oss trafikk Jul 06 12:47:49 alts?, 1500 etter at varnishd d?de Jul 06 12:48:02 tror det er en god nok m?te ? gj?re det p?. S? slipper vi ? configge hele tiden. Jul 06 12:48:07 greit Jul 06 12:48:11 det er dine lesere :) Jul 06 12:48:19 ja :) Jul 06 12:48:35 kan sette ned retry raten litt. Jul 06 12:49:15 >> AS3408-2 VG Nett - Real server 21 # retry Jul 06 12:49:16 Current number of failure retries: 4 Jul 06 12:49:16 Enter new number of failure retries [1-63]: 1 Jul 06 12:49:33 ^^ before de decalres dead Jul 06 12:49:41 he declairs :) Jul 06 12:51:45 I've saved the core, lets try again for another shot. Jul 06 12:52:09 sure :) Jul 06 12:52:34 When you start port 80 loadbalancer will send 8 req's for h.html then start gicing traficc Jul 06 12:53:00 ^^ Microsoft keyboard Jul 06 12:53:09 ok, jeg starter Jul 06 12:53:10 you need to get a Linux keyboard Jul 06 12:53:16 Yeah :) Jul 06 12:53:18 woo! Jul 06 12:53:21 boom. Jul 06 12:53:25 oops Jul 06 12:53:35 18 connections, 77 requests Jul 06 12:53:40 that didn't last long... Jul 06 12:54:41 longer than me :) *rude joke Jul 06 12:55:04 bewm Jul 06 12:55:22 can I follow a log? Jul 06 12:55:39 with: lt-varnishlog ? Jul 06 12:56:27 samme fejl Jul 06 12:56:38 andersb: jeg gemmer logfilerne Jul 06 12:57:00 bewm Jul 06 12:57:13 phk: Jepp, men for min egen del for ? se n?r dere skrur p? etc. Da l?rer jeg loadbalancer ting. Jul 06 12:57:51 ok, samme fejl igen. Jul 06 12:58:02 jeg foresl?r vi holder en lille pause mens jeg debugger. Jul 06 12:58:09 sure. Jul 06 12:58:16 andersb: cd ~varnish/varnish/trunk/varnish-cache/bin/varnishlog Jul 06 12:58:21 andersb: ./varnishlog -o Jul 06 12:58:37 andersb: cd ~varnish/varnish/trunk/varnish-cache/bin/varnishstat Jul 06 12:58:43 andersb: ./varnishstat -c Jul 06 12:58:44 eller ./varnislog -r _vlog3 -o | less Jul 06 13:00:02 Jeg g?r meg en kort tur. Straks tilbake. Jul 06 13:01:27 vi k?rer igen Jul 06 13:02:31 2k requests Jul 06 13:02:57 3k Jul 06 13:03:39 5k Jul 06 13:03:55 ser veldig bra ut Jul 06 13:04:06 hit rate > 93% Jul 06 13:04:13 95% Jul 06 13:05:14 800 objects Jul 06 13:05:32 load 0.28 Jul 06 13:05:37 0.22 Jul 06 13:05:52 CPU 98.9% idle :) Jul 06 13:06:12 4-5 Mbit/sec Jul 06 13:06:42 nice :) Jul 06 13:06:49 vi kj?rer til det krasjer? Jul 06 13:06:58 jep Jul 06 13:07:05 du m? gerne ?bne lidt mere Jul 06 13:07:20 okay Jul 06 13:07:41 3 ganger mer... Jul 06 13:08:04 si fra n?r dere vil ha mer. Jul 06 13:08:24 vi gir den lige et par minutter p? det her niveau Jul 06 13:09:17 bewm Jul 06 13:09:31 3351 0.00 Client connections accepted Jul 06 13:09:31 23159 0.00 Client requests received Jul 06 13:09:31 21505 0.00 Cache hits Jul 06 13:09:31 1652 0.00 Cache misses Jul 06 13:10:17 k?rer igen Jul 06 13:10:19 here we go again Jul 06 13:11:06 20mbit/sec Jul 06 13:11:09 100 req/sec Jul 06 13:12:30 nice :) Jul 06 13:12:46 det er gode tall, og jeg skal fortelle dere hvorfor senere Jul 06 13:12:49 steady 6-8 mbit/sec Jul 06 13:12:52 okay. Jul 06 13:13:00 ca 50 req/sec Jul 06 13:13:04 skal vi ?ke? Jul 06 13:13:14 ja, giv den det dobbelte hvis du kan Jul 06 13:13:19 vi startet med 1 -> 3 -> ? Jul 06 13:13:22 6 Jul 06 13:13:23 6 Jul 06 13:13:34 done Jul 06 13:13:42 den hopper opp graceful. Jul 06 13:13:54 boom Jul 06 13:14:06 :) Jul 06 13:14:11 men ingen ytelsesproblemer Jul 06 13:14:19 bare bugs i requestparsering Jul 06 13:14:20 k?rer igen Jul 06 13:14:26 bewm Jul 06 13:14:31 ok, vi pauser lige... Jul 06 13:17:40 jeg har et problem med "pass" requests, det skal jeg lige have fundet inden vi g?r videre. Jul 06 13:18:51 Sure. Jul 06 13:28:50 ok, vi pr?ver igen Jul 06 13:29:09 bewm Jul 06 13:29:35 more debugging Jul 06 13:33:56 OK, found the/one pass-mode bug Jul 06 13:33:58 trying again Jul 06 13:35:23 150 req/s 24mbit/s, still alive Jul 06 13:37:02 andersb: tror du du klarer ? komme deg hit til foredraget, eller er du helt ?delagt? Jul 06 13:37:06 andersb: giv den 50% mere trafik Jul 06 13:39:46 mer trafikk Jul 06 13:39:56 EvilDES: Nei :(( Men Stein fra VG Nett kommer. Jul 06 13:41:25 btw, har du noen data om hva load balanceren synes om varnish? Jul 06 13:41:50 jeg regner med at den f?lger med litt p? hvor god jobb vi gj?r Jul 06 13:43:10 Jeg genstarter lige med flere workerthreads... Jul 06 13:43:43 jeg tror 20 workerthreads var for lidt nu... Jul 06 13:43:47 nu har den 220 Jul 06 13:44:40 2976 107.89 Client connections accepted Jul 06 13:44:41 10748 409.57 Client requests received Jul 06 13:44:41 9915 389.59 Cache hits Jul 06 13:45:13 det var alts? 400 i sekundet :) Jul 06 13:45:45 og ingen indlysende fejl p? www.vg.no siden :-) Jul 06 13:45:54 bewm Jul 06 13:47:16 andersb: hvor stor andel av trafikken hadde vi n?? Jul 06 13:48:06 alts?, vekt i load balanceren i forhold til totalen Jul 06 13:49:20 ok, kun 120 threads s?... Jul 06 13:50:48 9 Jul 06 13:52:45 andersb: 9 -> 12 ? Jul 06 13:52:48 andersb: 9 til varnish, men hvor mye er den totale vekten? Jul 06 13:52:58 har vi 1%? 5%? 10%? Jul 06 13:54:37 n? passerte vi nettopp 50000 requests uten kr?sj Jul 06 13:55:36 maskinen laver ingenting... 98.5% idle Jul 06 13:56:21 12 maskiner med weight 20 Jul 06 13:56:26 1 med weight 40 Jul 06 13:56:29 varnish med 9 Jul 06 13:57:01 si fra n?r dere vil ha mer trafikk. Jul 06 13:57:02 9/289 = 3.1% Jul 06 13:57:12 andersb: giv den 15 Jul 06 13:57:44 gjort Jul 06 13:59:43 dette er morro. Jeg m? si det. Jul 06 14:00:27 20-23 Mbit/sec steady, 200 req/sec, 92.9% idle Jul 06 14:00:30 bewm Jul 06 14:00:46 OK Jul 06 14:00:57 jeg tror vi kan sl? fast at ytelsen er som den skal v?re Jul 06 14:01:33 det er en del bugs, men de b?r det g? an ? fikse. Jul 06 14:01:34 Jepp :) Det s? pent ut... Jul 06 14:01:53 jeg tror ikke vi har set skyggen af hvad Varnish kan yde endnu... Jul 06 14:01:53 andersb: hvordan ligger vi an i forhold til Squid? Jul 06 14:01:58 pent :) Jul 06 14:02:13 Jeg har ikke f?tt SNMP opp p? dene boksen, jeg burde grafe det... Jul 06 14:02:23 snmp kj?rer p? c21 Jul 06 14:02:33 tror agero satte det opp Jul 06 14:02:36 aagero Jul 06 14:02:38 Ja, men jeg har ikke mal i cacti for bsnmpd Jul 06 14:02:43 ah, ok Jul 06 14:03:03 men den burde st?tte standard v2 mib? Jul 06 14:03:26 det er ikke protocoll feil :) Jul 06 14:03:42 Hva er byte hitratio forresetn? Jul 06 14:03:52 det tror jeg ikke vi m?ler Jul 06 14:03:55 enda Jul 06 14:03:59 andersb: den har jeg ikke stats p? endnu. Jul 06 14:04:22 ok, forrige crash ligner en 4k+ HTTP header... Jul 06 14:04:27 (eller en kodefejl) Jul 06 14:06:03 andersb: pr?v at ?ge vores andel til 20 Jul 06 14:06:26 hvilken vekt har hver av de andre cachene? Jul 06 14:06:49 20 og en med 40 Jul 06 14:07:50 gjort Jul 06 14:08:59 440 req/s 43mbit/s Jul 06 14:09:17 bewm Jul 06 14:09:18 bewm Jul 06 14:10:30 oj Jul 06 14:10:39 vi var oppe over 800 req/s et ?yeblikk Jul 06 14:10:46 60mbit/sec Jul 06 14:10:52 og 90% idle :-) Jul 06 14:10:59 ingen swapping Jul 06 14:11:58 og vi bruker nesten ikke noe minne - 3 GB ledig fysisk RAM Jul 06 14:13:02 ca 60 syscall / req Jul 06 14:14:31 nice :) Jul 06 14:14:58 andersb: pr?v at give os 40 Jul 06 14:17:26 gjort Jul 06 14:18:17 det ligner at trafikken falder her sidst p? eftermiddagen... Jul 06 14:19:07 ja :) Jul 06 14:19:43 andersb: s? skal vi nok ikke ?ge mere, nu n?rmer vi os hvad 100Mbit ethernet kan klare. Jul 06 14:19:58 bra :) Jul 06 14:20:36 42mbit/s steady Jul 06 14:20:59 40 av 320? Jul 06 14:21:06 12,5% Jul 06 14:21:43 * nicholas (nicholas@nfsd.linpro.no) has joined #varnish Jul 06 14:22:00 det der cluster-noget bliver der da ikke brug for n?r vi har 87% idle Jul 06 14:23:05 hehe :) Jul 06 14:24:38 skal stille de andre ned litt for 48 er max Jul 06 14:24:57 jeg tror ikke vi skal g? h?jere f?r vi har gigE Jul 06 14:25:14 4-5MB/s Jul 06 14:25:32 lastbalanserer backer off p? 100 Mbit Jul 06 14:25:35 :) Jul 06 14:25:42 S? vi kan kj?re nesten til taket. Jul 06 14:26:01 hvis det har noe poeng. Jul 06 14:26:09 crash :) Jul 06 14:27:33 bewm Jul 06 14:29:08 Stilt inn alle p? weight 5 Jul 06 14:29:17 bortsett fra 1 som er 10 Jul 06 14:29:20 varnish er 5 Jul 06 14:29:24 s? giv os 20 Jul 06 14:29:51 gjort Jul 06 14:30:58 vi f?r kun 300 req/s Jul 06 14:31:04 Ahh der skete noget. Jul 06 14:32:41 ok, ved denne last bliver backend connections et problem, jeg har set dns fejl og connection refused Jul 06 14:33:10 dns fejl Jul 06 14:33:21 okay, pek den mot 10.0.2.5 Jul 06 14:33:28 det er layer 2 squid cache Jul 06 14:33:35 morro ? teste det og. Jul 06 14:33:54 det g?r jeg n?ste gang den falder Jul 06 14:34:48 jeg kunne jo ogs? bare give leonors IP# istedet... men nu k?rer vi imod squid Jul 06 14:36:05 ja, gi leonora IP det er sikkert bedre. Eller det kan jo v?re fint ? teste mot squid og :) Jul 06 14:39:04 nu k?rer vi med leonora's IP# Jul 06 14:39:33 nu k?rer vi med leonora's *rigtige* IP# Jul 06 14:41:20 Nu er vi f?rdige med det her 100Mbit/s ethernet, kan vi f? et til ? :-) Jul 06 14:41:42 lol :) Jul 06 14:42:00 For ? si det slik. Det tar ikke mange dagene f?r Gig switch er bestilt :) Jul 06 14:43:05 bewm Jul 06 14:43:13 ok, jeg synes vi skal stoppe her. Jul 06 14:43:41 jepp, foredrag om 15 min Jul 06 14:43:57 jepp Jul 06 14:44:23 disabled server Jul 06 14:45:29 dette har v?rt en veldig bra dag. Jul 06 14:45:49 hva skal vi finne p? i morgen? skifte ut hele Squid-riggen med en enkelt Varnish-boks? ;) Jul 06 14:45:53 lol Jul 06 14:46:15 * EvilDES m? begynne ? sette i stand til foredraget Jul 06 14:46:17 da m? jeg har Gig switch. Eller s? kan v?re b?re med en HP maskin ? koble rett p? lastbal :) Jul 06 14:46:22 kan vi ikke n?jes med en halv varnish box ? Jul 06 14:46:41 vi m? ha begge halvdeler for failover Jul 06 14:47:01 :) Jul 06 14:47:14 kan faile tilbake til de andre. Jul 06 14:47:25 Jeg klarer ikke holde meg hjemme. Jul 06 14:47:33 Jeg kommer oppover om litt :) Jul 06 14:47:39 Ringer p?. Jul 06 14:48:19 m? g? en tur n? :) Jul 06 14:48:29 * andersb has quit (BitchX: no additives or preservatives) Jul 06 14:49:44 http://www.des.no/varnish/ **** ENDING LOGGING AT Thu Jul 6 14:52:04 2006 *phk* Henceforth, whatever our philosopher says about Matter will apply to extension and to extension alone. It cannot be apprehended by sight, nor by hearing, nor by smell, nor by taste, for it is neither colour, nor sound, nor odour, nor juice. Neither can it be touched, for it is not a body, but it becomes corporeal on being blended with sensible qualities. And, in a later essay, he describes it as receiving all things and letting them depart again without retaining the slightest trace of their presence.483 Why then, it may be asked, if Plotinus meant extension, could he not say so at once, and save us all this trouble in hunting out his meaning? There were very good reasons why he should not. In the first place, he wished to express himself, so far as possible, in Aristotelian phraseology, and this was incompatible with the reduction of Matter to extension. In the next place, the idea of an infinite void had been already appropriated by the Epicureans, to whose system he was bitterly opposed. And, finally, the extension of ordinary327 experience had not the absolute generality which was needed in order to bring Matter into relation with that ultimate abstraction whence, like everything else, it has now to be derived. That the millionaire was genuine, ¡°in person and not a caricature,¡± as Dick put it, was evident. Both the nurse, his relative, and his wife, were chatting with him as Jeff delivered the heavy packed ball made up of the gum. 233 "I guess not," said Landor, tolerantly, as he turned[Pg 106] his horse over to his orderly; "but, anyway," he added to Ellton, "we had a picnic¡ªof a sort." Si, unable to think of anything better, went with him. The train had stopped on a switch, and seemed likely to rust fast to the rails, from the way other trains were going by in both directions. The bridge gang, under charge of a burly, red-faced young Englishman, was in the rear car, with their tools, equipments, bedding and cooking utensils. THE DEACON HAS SOME EXPERIENCES WITH THE QUADRUPED. "You are not within a mile of the truth. I know it. Look here: I believe that is Gen. Rosecrans's own cow. She's gone, and I got an order to look around for her. I've never seen her, but from the description given me I believe that's she. Who brought her here?" "Deacon, these brothers and sisters who have come here with me to-night are, like myself, deeply interested in the moral condition of the army, where we all have sons or kinsmen. Now, can't you sit right there and tell us of your observations and experiences, as a Christian man and father, from day to day, of every day that you were down there? Tell us everything, just as it happened each day, that we may be able to judge for ourselves." HAS AN ENCOUNTER WITH THE PROVOST-MARSHAL. "Wonder which one o' them is the 200th Injianny's?" said Si to Shorty. "And your mother, and Harry?" The daughter must be the girl who was talking to him now. She sat on a little stool by the fire, and had brought out some sewing. "Over at Grandturzel¡ªcan't see wot's burning from here. Git buckets and come!" These things, however, gave little concern to the worthy who commanded the Kentish division. Tyler, though an excellent blacksmith, possessed few of the qualities requisite for forming a good general. Provided there was no very sensible diminution in the number of his followers, he cared not a straw for the score or two who, after quarrelling, or perhaps fighting, withdrew in such disgust that they vowed rather to pay the full tax for ever than submit to the insolence of the rebels. One man could fight as well as another, reasoned he; and, provided he was obeyed, what mattered it by whom. Dick went and Tom came¡ªit was sure to be all one in the end. But this burst of indignation soon passed away, and upon the suggestion of the prudent Sir Robert Hailes, he sent an evasive answer, with a command that the Commons should attend him at Windsor on the Sunday following. That it was a stratagem to gain entrance to the Tower, was the opinion of several, but, after much discussion, it was decided that the man should be admitted, and that the monk should be exhibited merely to intimidate the rebels, until the result of this promised communication should be known. HoMEŮͬÐÔÁµcbcb ENTER NUMBET 0017
www.xumei8.net.cn
www.difa2.net.cn
www.ziranba.com.cn
www.qpq.net.cn
www.oukey.com.cn
yanmi6.net.cn
mamen9.net.cn
mucan5.net.cn
www.alphatrend.com.cn
andfin.com.cn
张柏芝露b 尻逼逼影院 人体艺术avav 动漫黑人图 五月天欧美色图片 小妹妹人艺体艺术 三集片huaog WWW.JIJIZY.COM WWW.USQ6.COM WWW.85KKKK.COM WWW.QI-WEN.COM WWW.SE9992.COM WWW.09ZZZZ.COM WWW.HNLYTF.COM WWW.TJKPZX.COM WWW.ZXSP68.COM WWW.HHH840.COM WWW.MV94.COM WWW.114066.COM WWW.61PPS.COM WWW.313K.COM WWW.HHH131.COM WWW.CL611.COM WWW.WJJSOFT.COM WWW.976QQ.NET WWW.RE219.COM WWW.TTXUTZF.COM WWW.410R.COM ABU.OMAR WWW.74TGG.COM WWW.18AVDAY.COM WWW.BBB710.COM WWW.CWGRC.COM WWW.AA717.COM WWW.H9XR.COM gehentaiorg 哥哥姐姐综合社区 av毛片无码片 99re5久久热在线播放快 俄欧美妈妈与儿子乱伦 骚逼被操视频哥哥去哥哥色爱操逼 好好干亚洲老太太b WWW44rerecon www9696h wwwasw4444com 依依社区人妻图片 东京热苍井空QVOD www_东京热_com 意淫强奸人妻女友 真人性爱姿势电影 淫系列 有声书收听 免费av在线看 在我AV天堂 www日本黄片 日韩千部黄色电影 2012天堂伦理最新加勒比 唐山大兄 在线哥哥去 一木道福利 草榴社区2016 插我的小tube avtt2020 亚洲性爱-脱光干X网 WWW_ANQUYE789_COM 久久热集百万潮流 www5060lucom av999偷拍自拍 濑亚美莉磁力连接 成人美女游戏 色色网激情视频学生 手机版人与动物啪啪 清纯女友被轮奸调教 午夜网址大全 刺激撸的网站 久久影音手机版下载百度云 游戏人体艺术 q播自拍偷拍 wwwxxooluolicom 监狱里的大鸡巴 羞涩影院会员 www903sscom 石家庄少女的性爱视频 日本儿子五月天 黄色片xxx 熟女成人乱伦做爱免费视频 骚鸡鸡 2015狼人av综合 www7xpxpcomftp 全国黄色片子 美国新农夫综合 wwwmcc222com 岳母在线观看 日日射日一日fi79com 萝莉h在线看视频 港台美女 变态另类欧美性爱av天堂2014 wwwnn535c慰m Www331com 古墓丽影h版免费观看 国产父女乱伦小说 蔡依林纹身图案 女人17P 强奸乱伦最稳定网站 自偷自拍百度百度 日本激情点的床上男女 坠落色戒 凌辱女友mcc色站 亚洲男女淫秽乱伦性交色图 wwaisedizhicomcom 作者不详bt工厂 91porm手机端 新新影院若怒 人妖性爱高潮图片 CK在线看 日本阴户视频美国人曾交 熟女露逼口交 国产图片成人av小说wwwlsy2016com sm车神 www115cdcom 大奶娴的调教qk3pcom 爷爷和孙女乱伦影片 美女做爱自拍25P 亚洲欧美色片在线播放 日本丝袜熟妇乱伦 琪琪自拍偷拍 黑丝诱惑亚州性夜夜射 412vvcom www510ddc5cbiz 骚逼姐姐的大屁股 色色鸡巴图片 cluanlun 大肥婆性爱 尤娜种子 00后人体图片少女无毛掰开图片 快播人与马交配 全祼体女张筱雨 乐乐形式亚洲色图 偷拍自拍模特mb 成人在线骚逼女人 高清图片网站裸体丝袜熟妇 色 五月天 婷婷 快播 抽插逼图片 11xingjiao 拳交 am 人体艺术女人最大胆的高清阴道全裸图 好色猫欧亚色图 人与曽肏屄播放 baguacaobi 同志做爱视屏 2014吉吉影音三级片 成人美女贴图 人體圖片網 色色人导航 天天撸夜夜撸高清色图大图 插美人老师 WWW_JDMI_COM hp之报应来得快 天籁地球村 名字测 董文华儿子 鞋子大全 亚洲视频新 日本人体里美尤利娅 草比阴影先锋 张柏芝的黑木耳西瓜 美女老师光屁股 猛插青空小夏骚穴图 日本人口交图 熟女肛交30p wwwdd43com 少妇大胆阴部大bb图片 快播ay 张柏芝艳照门高清下载 sao8080c 美女美穴图片30p 乱伦大鸡吧操逼故事 五月天duppid1 mac版淫色网站 岸明日香ed2k 色撸撸色图 惊变激情戏在多少分钟 人体艺术大图下载 圣后骚货 高清无码母乱伦 8090色色网 美女图片大胸删除 明星性交合成骚图 大胆漏阴人体艺术 美女行爱视频 插娇艳欲滴片阴 光棍影院丫丫11111 超碰最新视频精品视频wwwjd993com 淫淫操淫淫逼 女人露全乳图片 久草在线资草免 暴露女友轮奸 美女骚穴值得一日15P 欧美阿v女星播放 曰本色惰 国产超级法在线 色狗成年综合伊人 俄罗斯成人免费视频gegequlucom 33连导航农夫十次了 日本丰满肉弹熟妇 大香蕉伊人Tv 搜索色色色生香 三浦敦子mp4 伊人香蕉网WWWtr668com 黄色视频播放器wwwyehaobo7com 学姐的卫生巾 wwwse青青草com 骚美女36D 村上理沙手机在线播放 胔死我了爽啊 麻椒直播百度百科 岛国肉戏片在线下载 色中色成人黄色影院 12p黄色 爸别舔了啊轻点 超碰视频在线am 外国人做爱爽图片 有没有不不需要播放器的毛片 shkd官网 狼人干综合在线视频久久14iycom 黄色录像同性恋口交 处女红舒淇 熟女您射 有声小说推荐 诗春色 小泽玛利亚成长 小泽玛利亚现在 没病毒的h网 www酷狗音乐com www小沈阳com 四方伯伯开心五月天 精彩电影 天然素人 我也去色 妹妹AV综合 强奸迷奸做爱 910668快播 色大姐 撸撸管 doa成人电影 天堂网014 男同chinese帅哥gav玄兵 牛叉b电影435yy 千人斩的电影天堂 乱伦视频app 亚洲AV外卖 migd-4188 白鸟寿美礼电影伦理片 水之声动漫 wwwes18 妹子被干B 性感女秘书肉丝超短裙加班时被经理扑倒操爽后说 我等下要喷潮了 好痒啊 你快点 办 心动网址你懂视频 曰韩后入视频 日本情爱电影 日韩AB首汉-尿色电影 人人干人人 ts 艾彩trample 轻轻搞m3u8 新视觉a 五月丁香综合缴情香蕉 2014Aⅴ天堂 色奶妈在线 4hu 1122 在线偷拍自拍图片 97视频日本一本道 强奸超碰视频 黄图女性全身照 haodiaoyin这里只有精 凹凸视频 youjiz 吾爱久草福利导航 超碰视频在线美女逼 bunnybunnylove福利 伦理片adfy 流氓医生和俏护士视频 欧美强奸视频在线网站 777福利导航 直播偷拍在线观看视频 i8宝马影院在线 做爱黄福利影院 嘬大鸡巴 五月青青草 国产夫妻找人玩3p漂亮媳妇被单男猛操连续高潮磁力 外国XⅩx在线 高清无码色欲迷墙 jufd_409在线观看 hu99 播菊网 人人看人人爱人人妻 欧美性爱网进口 成人caohub AVOP127无码 ftp 冯熙璇 (春夏女装) -(帆布鞋) 东北娇妻土豪视频 X 影片名:网红美女演绎学生看到老师穿着高跟丝袜很性感就尾随跟到家里和老 国产成人啪啪自拍 91免费免费视频在线观看噜噜 SD001丝袜电影 欧美图片自拍图片 111pdy最新地址 久久热在线视频国产91大神熊哥 色酷狠狠干 wwwAV手机 手机看片动图 色偷拍亚洲偷自拍在线视频 筋流在线播放 757午夜福利影视1000 米奇大香蕉在线视频 百度热搜推荐乱伦自拍 西瓜影音 k8经典邱淑贞 无影院码 将军肉公主成人漫画 av在线日本人妻无码 亚洲欧美中文日韩在线无码 av淘宝视频在线分类 拉风色国产 初中白丝自慰 SHIB-026 神山美羽 魅惑の縦スジ 绿茶导航国产 午夜福利236 超薄丝袜约炮 制服诱惑快播涩 日本高清无码美女视频 日本性乱交视频 丝袜在线观看综合 97起碰在线自拍 3344动画伦理片 在线拍 A级片互舔 2828sezy 学院女神 富二代三亚 萝莉学生视频 大象视频福利 香艳视频集锦 学生妹诱惑福利合集 magnet 邪恶里番肉番 香蕉视视频app 消失的说说日本伦理 日本一本道黄色视频在线播放 美国成人综艺节目磁力链接 里番无修手机在线看 松岛绫花步兵下载 亚洲 日韩 在线 制服 午夜高清自拍 狂胔美女空姐小说 大学生偷拍自拍 免费操逼黄片大全 rion 先锋在线 俄罗斯性爱茄视频 久播 福利 内射av小视频 主播 和 狗 交 配视频在线观看 福利小电影在线观看免费观看 干阴逼 MIAD-937 magnet 一本道,东京热第一页 abp561c 毛片激情直播网站 86手机在线看a片资源 国产偷拍 欧洲激情 操碰色区 999xdv 777影院 亚洲性直播live 红阁番影院 日本一本高清无码mv 22bbbb 亚洲人成网站在线播放图片 第一综合色站 real睿宝内部V8视频种子 国产真实偷拍啪视 在大街上穿着裙子没带自慰棒视频。 logdown永久地址 手机看黄片红楼梦 日本天天干 午夜11p 日本鲜肉gv百度云 啄木鸟在线观看免费 4tubesex deos曰本 a性交视频 成人手机福利,车上各种 俄罗斯美女裸体黄片 日本高清视频网页 爵迹2迅雷磁力链接 不用下载的免费操逼视频 综合色爱视频 黄色美女干黄色事 换妻性交真实影片 久久国产在线野战 AV淘宝2018在线 4438成人网(开心五月) 国产综合色 xo168惰色在线 南里美希泳装 手机自拍偷拍强奸乱伦 超碰成年人福利无码 日本女人女同视频 麻生千春视频 极品外围女模特拍摄时被摄影师勾引 拳脚周晓林在线播放 先锋影音:超模全裸大片 安全的免费av 沉香 性欲 邱县特级黄片 立川理惠七夕电影在线 美女被孼 国产自拍伦理电影 日韩理论大全视频 淫妻小说 爱丝小仙女思妍白丝 熊猫tv杜姗姗私人视频 和刚下班的白领在洗手间 好看的中文字幕色拍拍噜 92福利自拍 AEEN资源 迅雷 下载欧美女优 国外一级录像 熟女性生活视频在线观看 莲实克蕾儿 中文在线 91秦先生小明看看 冴岛香织在线av AV在线论坛 江疏影2分钟视频链接 那种女的虐女的番号 亚州福利电影 国产张飞跃在线播放 国产自拍第9页 韩国三级理论福利视频 色吧 春暖花开春暖花开 最新福利短视频在线 手机在线好吊草视频 国产超高级自拍 龙腾色狼 性交2018国产久久精采视频 网红h视频迅雷下载 magnet 国产a片作品 2017亚洲天堂在线av电影网 苍空 手机观看网哈 xⅩxSex 4438x 1成人网 奸轰片 国产自拍欧美视频 huangsedepian 亚洲成八综合视频 第四色先锋色色 国产熟妻女人在线视频 人妻生活前编在线观看 欧美爱爱插小 黄s网大全 少女水逼 色人党苍井空 俺也撸激情明星 在露沐浴和大奶子美女做爱 做爱黄色图片网站 优酷爱疯主播分成 和丝袜老师做爱 999色网 苍井空的色墙 被男友狠狠玩奶子骚穴 日本国模人体艺术图片 裸体性感欧洲帅哥 白虎裸体艺术 最新豚眠影音先锋 恋足舔脚视频 色99色 132renti 大学生援交50p 欧美色图很很lou 我把岳母操的狂叫 大胆人体组图 马六人体高贵美 妇 女人秘密处动态照 性感黑丝小骚逼 WWW_BBSTT86_COM 天堂岛男人的天堂 少妇爱大鸟【15p】怡春院百度 大战熟女记txt 日本漫画的人体艺术 哥哥射 p 操乡下熟鸡 夜射猫在线播放 岳母和女讯做爱 国产cenren 美女嫩逼50 谷歌大胆人体艺术图片 ed2k无码女同番号 空姐的秘密狠狠干 梦意杀机 北京函授大学 亚洲成人美女性交区 泰妹性交做爱 狠狠影院下载 WWW_WW945VV_COM 张筱雨棵体艺术写真集 不穿衣服的美浪妇 草别人媳妇 成人花花公子导航 日本美女裸体大全 xunleimianfeidianyingxiazai 妈妈操逼色色色视频 狠狠干meinurenti aiyishu 插老师导航 avhbocom 那英性爱1级片 欧美操屄上视频 我想和亲妈发生过关系 黑人干美女的的电影 国内丝袜大妈图片 美女大胆人体丝袜 400色色色 chabibiantai 国内乱妇乱伦 stoya图片裸照 黄色3及 色妹妹口交吃精 小明看看平台se7se7 熟女大姨 人与兽影音先锋播放 宫本由美淫 有人体色图 明星色图29 辽大bt 日韩孕妇做爱 乱伦文章天天色 我的妈妈是淫荡老师五十熟女 喷奶三级片 WWW777VFCOM 欧美与亚洲色片 换妻不要停快操我的屄 饭冈加奈子男人最喜欢的类型网传 最大胆亚洲裸体艺术 国产自拍土逼视屏 拍照做爱 我被两个老外抱着干 狂插白洁 强奸伦理片 逼图片第26p 亿性家社区视频 成人片最新狼友 733动漫网成人片影音先锋 姐妹妈妈阿姨日逼 综合插插a 日本A片899jjcom 岛国鲁炸天在线影院 欧美性交操b 2017丝袜少妇贴吧 好想要性生活 欧美成人教育片巨乳wwwmjlnihydbufcn savsopwcn 小说区视频区欧美时尚自拍偷拍 成人丽丽 亚洲性va在线观看百度 淫妻丝袜小说网 骚妻小莹 操性奴女 白虎人体艺术 亚州淫性片 中年操 佐山爱女友的姐姐下载 大香蕉之肥胖熟妇在线视频 古典武侠第四色色午夜 成濑心美2017人体 免下载偷拍黄色 风流少妇人体艺术图片 欧美桃在影院 性感丝袜漫画美女图片 免费看欧美黄色大片网站xxx 家庭老师姐姐的诱惑漫画 男孩操的女孩好爽视频播放 舔大学美脚微博 天津爆打桩系列在线 wwwcaoxiu184co 噜wwwav567net 日韩黄色女忧 欧美男女操逼图像 图片色姐妹 老岳母的肥乳 在线成人电影免播放器免下载2014成人视频免费在线观看 自拍丝袜欧美偷拍 美乳翘臀自拍偷拍 成人电影实战 少女手淫偷拍视频 奸入女儿 www图图成人站 表姐在车上让我插穴 超市强暴在线 亚洲巨乳少女色27p nass系列合集 偷拍自拍自拍一区在线观看 3p4p做爱 成人有声读物 上了个美女亚洲色图 metartvideosxxx av大腿夹射系列 能手机在线看的福利长片 爆乳美女无码15p 夜射猫精品乱伦 青楼社区免费观看 另类专区自慰在线wwwhhxxoo1com wwwzly99com 人人操色8 色网p 少妇激情综合站 熟女内裤艳照 成人偷拍自怕免费在线电影 逍遥牛牛官网 无毛小穴 7777avcom下载 妈妈撸狠狠干 wwwll777 大黑屄插插插 草榴社区2012网址 carporn欧美网站 顶破av片 黑老大插插 狠狠偷2016你懂得 aboutblank约炮 肉洞肉棍口交 撸管网址淫色帝国 中年同志叔叔的大老二 play视频资源 色尼姑色尼姑在线色尼姑图色尼姑影院 四房播狠狠撸 player亚洲有码 亚洲色图人妻乱伦手机版 jjaz_com黄色网 超碰羞羞 徐冬冬吃男人鸡巴视频 凌辱 武侠激情都市小说 大炮撸在线影院 清纯唯美激情五月姐姐 色阁第色季姐妹爱情 黄色片黄色视频黄色论理小说 长沙哪里有A片购买 美国妓院电影操我 色尼姑久久超碰视频在线 www五月天cm ttjh113dddcom 亚洲欧洲另类视频在线 极品日本熟女人妻 白领制服丝袜控在线视频 淫乱伦性爱电影 嫩女自拍 Xxoo88 114张悠雨魅惑图片色色看看色色看看主 老婆在我面前小说 真人性爱姿势动图 有什么外国人兽网站 wwwluluhetv女 和弟弟交尾 性交实拍舔鸡巴1000部 丝足交小说 美女明星的人体素像 www942tvcomwww942tvcom 看美女ys avdian126cmo 风暴AV天堂2015在线 褪色膏 大奶屄视频 ppypp影视天堂手机版 人人摸人人干888excom 成人动漫东方 性爱动漫在线免费 高清无码日本下载 小黄漫画书在线看 咪咪网络 苍井空人艺体图片大胆 裸体艺术爱人体ctrl十d ccc36色女孩 看兽性交 网友自拍暗暗撸 女人与兽做爱小说 人人色色成人专业操逼视频图 亚洲p炮综合图 熟了网 女优性交免费电影 鲁特特色中色影院先锋 caopiwangzhan 饭岛爱图片网 菠萝野结衣演过多少部电影 好看的电影特级黄色图片 兰桂坊人成在线视频 刑讯女小说 调教日本女优 wwwav777con 少年与熟妇爱图 女子与爱狗拔不出视频 哇嘎成个人社区米奇 熟女屄毛 风骚系2 小说 台湾强奸潮 操bi视频 美奶子 狠狠射狠狠操色妈妈色姐姐 激情乱伦口述 色狗中文字幕qvod 亚州偷拍自拍露奶子 女忧私处艺术 我在这里等你歌词 孤芳不自赏天天天影院 大学生做爱下载 丝袜内射吧 xxx大胆人体艺术 caoporen—在线视频 大胸长腿丝袜裸照美女 李宗瑞强奸mia 美女裸漏下阴 长泽锌胖瘦刚刚好的爆乳女吉吉 去撸吧社区亚洲视频 14岁儿子与母亲性交 大胆男人人体写真 WWWWWNNVCOM www844con 欧美色炮爱爱 做爱用品 妈妈再来一次波多野结衣快播 哪里有正规网站黄色小说 淫妻张敏阿红和公公乱伦 freefron快播 下一篇内射3p 真实的骚妇 欧美人妻肉射wwwqqqq68com 母婿口交乱伦 天天好逼百度影音 绝色贵妇丝袜小说 女厕所里熟女手淫视频 哥也色屄屄 舔阴蒂偷情 骚货操的你爽不爽 18岁以下禁止视频myoukucom 滛乱网www78iiiicom dizhi调教 日日夜夜鲁妈妈鲁播放人妖 狠狠射性感美女屁股图片 884aa在线wrsyioxjnlncn 琪怡红院 印度美女腋毛 中亚美女性爱图 电动抽插阳具下载 1314狠狠撸亚洲 jav女优网站 WWWKKKSSSC0m 欧美潮喷av网 wwwbbfulicomdianying AV群交游泳馆 咪咪爱网址最新百度 www优妓种子 黑屌曰幼女 黄色读书乱伦 明星av手机在线视频 春药催眠magnet 东京热淫乱人妻 裸体少妇阴道 另类有声小说 程蝶衣知春色 类似春色 樱井莉亚种子 小泽玛利亚av3gp 小泽玛利亚全片 求无毒h网 电脑能上的h网 色五月开心五月天 50268669东京热 手机可以看的黄片 黄网看黄片 黄色小说群 四房播 狼友之家 色既是空 高清做爱图 哥哥色在线 良人社导航 天天she app午夜快播免费1000 中国国产凤凰av 22 xhatmer 18 哥也色看不了 青青国产中文在线 轻吻也飘然 520少妇全集 全套服务在线云播 让人湿的文字 青草日日视频 讯雷哥云手机在线视频 人妻群p视频自拍 日韩 偷拍 自拍 在线 日本日日摸 女人天堂a视频区 茄子影院在线播放 手心影院黄色免费视频 乳交视频免费 f86080新视觉影院官网 259luxu日本线上资源 wwwsheshe88 欲色音影 日rrr 成人福利在线免费超级碰 4438xx1路com 番号去哪下载快 www,551777,com 人妻痴汉电车中文字幕 九九自拍视频在线观看 理论片老四影院 神马伦理不卡 国产自拍12 4蝥你V 治愈的不足的淫语引导到绝顶的回春旗袍 主播迷迭香磁力 早乙女由依视频手机在线观看 k45vcom平台樱桃 中文字幕成人 天天啪夜夜日日日干 电影港福利 大香蕉电影院 magnet 色狐狸av免费澳门 上原亚衣av片 wwwkk55kkcn 草民影音牛牛电影 欧美六九视频 AV黄色野战 我的世界女生自慰视频 大片播放器 x91毛片 出差招妓4P超爽 德国人xxx 成人影院看三级黄牛 大香蕉成绵乐 亚洲性爱米奇777 香港日本韩国台湾黄片 好看的国产自拍-最新国产自拍 17she009 亚洲激情无码视频 国产偷拍人妻自拍 汉庭酒店无码自拍 236宅宅网手 四虎影院紧急通道 ggmmkk 筋流在线播放 av电影大全亚洲天堂 大吊爆 葉S一红衣玩双奴视频 文静性感的大奶美女周日被男友带到出租屋挑逗后用尽全力操的美女说:我要,快点 vvvv999 伊人影院永久网址 色琪琪综合 XOXO未满十八岁勿进 色和日一本 白丝网站你懂的 成人视频在线天天喷 亚洲色逍遥社区com…… fset-487 绿衣超正初中妹三分钟 国产小黄片磁力链接 理伦片神马黑人 真人兔女郎福利视频 日本成人视频手机在线 MIAD-921中文 14girl色系 Japan inporn 酒店卫生间操女朋友 88titianm88 wwwnkmp66com 舔花核 小仙儿合集迅雷链接 性交视频新影院 学生自摸出水a片视频 处女操b电影 澳门香蕉操逼视频 东方库影,永久在线 若菜奈央716在线视频 911福利社区免费体验观看 福利 影院 bag 污直播视频还免费观看 日本三级做爱处女视频 强奸迅雷下载 magnet 2018午夜福利电影757影视 泰国美女需要体内射精在她的小阴户 桃色三国里番在线观看 俄罗斯另类三级小影院 熟女人妻 - 毛片基地 西瓜影音 轮奸路边小骚货干完还一人一泡尿迅雷 偷拍美女浴室伦理电影 夜店长裙番号种子 喵av 被窝久草影院 不卡的在线美女va视频 草榴影院中的黄色视频 被窝福利电影201 超碰超色超摸超操在线电影 太平天极jk 谁知道四虎影音最新地址 中文字幕rct-470在线 3d真人动漫xoxo漫画 十宗罪 ftp 喵喵AV网 彩色天堂网 操小逼出血视频 百人大战手机在线观看 成人逼b视频 vlc成人 操逼內射免费视屏 ssni209字幕网连接 siri自拍在线 有关很色的免费视频 在线视频播放你懂 华人play在线视频bbb kagp 019 丈夫不在家被肉棒操到红肿 喵了个咪av 蓝沢润 porn 珙琪影视在线观看 秋霞吧2017午夜电影 538在线精品牛牛 3手机激情在线成人影院 女主天地调教免费视频百度云 草莓在线视频免费观看e 不打码视频网 变形小雷 西瓜影音 国产偷拍第一页在线视频 下载黄片儿的。 mp4 视频里面看黄色与臀尖强奸情节故事视频里面看黄色录像强奸与通奸的故事 偷拍自拍第八十五 日本eeeex 一个美丽的嫩少妇15p 猫咪AV最新地址 成人影院官网 78福利影院伦理 无码xxxuom 俺来啦俺去啦新官网婷婷 国产自拍鸭子在线播放 怡红院依人香蕉 淫操初音女神 福利视频导航站 每日在线av免费视频每日更新 撸啵英视 裸体艺术广场舞资源在线播放 神马2018午夜影院 美国毛片基地A级e片 美国十次大公鸡 火山小黄福利视频 秋霞福利视频微拍 朴妮唛露私处完整视频 蚯蚓yy408 文在寅尻 99精品任你干 欧美日日B视频 抽插福利 偷拍广东情侣野战视频 jjzzseqing av福利资源 影豆网手机在线官网 二区每天更新不卡在线视频 花街在线AV 女人与狗ZOOXX 黄片男在上女在下视频免费 狠狠快点在线影视 小恶魔宇佐美奈奈 下载 亂倫文寃 白丝女主播自慰 德田重男作品迅雷种子全集资源 ibw619 影音先锋资源欧美啄木鸟剧情 律师娇妻之我妻只为他人淫 MSWD-10023 ftp 大屁股BT种子 色拍拍电影院 国内自拍在线偷拍大学色戒 嫩嫩影院 免费福利视频av 米歇尔贝瑞特 磁力下载 99y伦理 星野亚希校服 先锋 校园chunse tpzp 操心术在线观看 厚丝袜约炮 日本人口做爱姿势视频 美女午夜大片 15 H版暮光 开心激情网在线观看 乱伦儿媳妇大香蕉视频 迷干资源在线 gaonvnvnet 谁有艳照的网站 妈妈跟狗搞 欧美小姐120辣p图片 裸体后妈图 美女大尺度顶级图 小美女春暖花开亚洲 743vv 美女外拍全露出 亚洲蜜桃诱惑 爆插美女穴